hidden.
>
> In addition, your commit message is missing a sign-off line. You can add
> one by passing `-s` to git commit but you should read about what it
> means in [[sign-off]] in SubmittingPatches.
>
> > From: Michael Platings
> >
> > ---
> > t/t8014-bla
Thanks very much for this Derrick. I looked into it and it turns out
that the missing coverage in blame.c for "certainties[i] =
CERTAINTY_NOT_CALCULATED" was due to earlier code overwriting the same
value in most cases, thereby defeating an optimization. I've deleted
that earlier code and now cover
Hi Junio,
The SQUASH??? patches look good to me. Please squash away!
Thanks,
-Michael
On Fri, 17 May 2019 at 06:12, Junio C Hamano wrote:
>
> Barret Rhoden writes:
>
> > From: Michael Platings
> >
> > ...
> > Michael removed the bashisms from the tests.
>
&g
> My main concerns:
> - Can your version reach outside of a diff chunk?
Currently no. It's optimised for reformatting and renaming, both of
which preserve ordering. I could look into allowing disordered matches
where the similarity is high, while still being biased towards ordered
matches. If you
Hi Barret,
This works pretty well for the typical reformatting use case now. I've
run it over every commit of every .c file in the git project root,
both forwards and backwards with every combination of -w/-M/-C and
can't get it to crash so I think it's good in that respect.
However, it can still
On Sun, 14 Apr 2019 at 11:24, Junio C Hamano wrote:
> > If you only enable blame.markIgnoredLines then the hash for
> > "unblamable" lines appears as e.g. "*3252488f5" - this doesn't seem
> > right to me because the commit *wasn't* ignored,
>
> I think you misunderstood me. I was merely suggestin
> > + the `blame.ignoreRevsFile` config option. An empty file name, `""`,
> > will
> > + clear the list of revs from previously processed files.
>
> Maybe I haven't read this carefully enough but the use-case for this
> doesn't seem to be explained, you need this for the option, but the
>
On Sun, 14 Apr 2019 at 04:45, Junio C Hamano wrote:
> Wouldn't this make it impossible to tell between what's done by such
> a commit that was marked to be ignored, and what's done locally only
> in the working tree, which the users have long accustomed to see
> with the ^0*$ object name? I think
> - I wonder if the hash used here can replace what is used in
>diffcore-delta.c as an improvement (or obviously vice versa), as
>using two (or more) ad-hoc fingerprinting function without having
>a clear reason why we need two instead of a unified one feels
>like a bad idea.
Hi J
is going to be interested in
this issue and would prefer that I let him know sooner rather than
later.
-Michael
(resending in plain text, sorry for the spam again)
On Sun, 7 Apr 2019 at 23:52, David Kastrup wrote:
>
> mich...@platin.gs writes:
>
> > From: Michael Platings
>
Thanks Barret.
I've cooled off on the git-notes idea since learning that notes
branches have to be pulled explicitly. And different people may have
different ideas about which types of commits they want to ignore, so
not predefining the name of the ignore file(s) does seem like the best
option, eve
> Another good place to keep these revs is git-notes,
> which probably could result in faster lookups too and can be made
> visible in git-log.
Oh wow, I really like this. A major concern I had about the revisions
file was that you don't know what a revision ID will be until it's
upstream. If you
> Obviously this isn't as automated as saying "ignore commit X, it's just
> variable renaming". But it also eliminates the need to a priori figure
> out all such X that affect the lines you care about. You get an answer,
> your human mind says "nope, that's not interesting", and you press a
> butto
Hi Barret,
> I work on a project that needs a major reformatting, and one thing
> delaying me was the lack of an ability to ignore commits during blame.
I think we understand each other well then - I'm working on a plan to
change the variable naming rule in LLVM, and naturally other
developers ar
t;fuzzy heuristic" so I'd love to get
your take on it.
Many thanks,
-Michael
On Mon, 25 Mar 2019 at 02:39, Junio C Hamano wrote:
>
> mich...@platin.gs writes:
>
> > From: Michael Platings
> >
> > Hi Git devs,
> >
> > Some of you may be famil
15 matches
Mail list logo
