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
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
>
> - 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
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
> > + 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 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
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
> 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 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
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
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
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
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
> 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
> 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
15 matches
Mail list logo
