Re: [lmi] Zebras in Git

[Greg Chicares]

On 2018-04-24 20:48, Vadim Zeitlin wrote:
> On Tue, 24 Apr 2018 18:04:29 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I'm still not satisfied: I want git-diff to tell me that the cyan and
> GC> fuchsia blocks are identical. Or maybe that's actually what "color-moved"
> GC> is supposed to indicate?
> 
>  Yes, this is the entire point of this option.

That is so cool.

> The changed lines are still
> shown with the removed/added colours instead of the zebra colours
> (red/green by default). E.g. if I apply the following patch:
[... snipped ...]
> Then "git diff --color-moved" shows the last 3 lines in green (because I
> surreptitiously changed the cap style), the corresponding lines starting
> with "-" in red (removed), and the rest of the "-" and "+" lines (except
> the new line before the ctor, which is also added, and hence green) is
> shown in color.diff.{old,new}Moved colours.

I guess I'd better read up on 'color.diff.*', to make this more useful.

>  BTW, with code which is just moved, I couldn't see any utility for
> --color-moved=plain, but with the patch above, it's actually useful as it's
> more precise and highlights only the pen.SetCap() line itself differently,
> while zebra apparently has some minimal block size.

Realizing that you had introduced some changes to prevent this from
being a pure move, I had stared at the diff (without "plain"), and
was puzzled by the line immediately after "pen.SetCap()". It was
highlighted as a change, yet I couldn't perceive the difference.
Finally, I copied it to the clipboard and pasted it in after '/' as
a search command, which proved that it really was unchanged, though
not highlighted as a move.

It's far easier to use '--color-moved=plain', which just does the
right thing. Good example.

> GC> But...why wasn't "dimmed_zebra" dimmed?
> 
>  I'm not sure why did they call it "dimmed", but OTOH I can't think of a
> better name anyhow... AFAICS it just doesn't highlight the "-" moved lines
> at all and highlights the "+" moved lines in reverse video. It might be
> less confusing/more readable than "plain" or "zebra" when there are many
> moved blocks, I guess.

With presumably default git color settings, "dimmed" looks to me
like an almost imperceptibly dimmed white--e.g., (248,248,248)
as opposed to (255,255,255)--and I get no reverse video.

Some other option showed pure moves in italic; that was nice.
I'll have to customize the colors someday.

> GC> BTW, did you also notice the '--anchored=' option?
> 
>  I was vaguely aware of its existence, I think, but I don't remember having
> ever used it in anger.
> 
> GC> In the past, I used such an option with an ancient GUI diff program for
> GC> reviewing changes of this nature. First force the moved parts to line
> GC> up, and make sure there's no change in them (which would be
> GC> highlighted); then un-anchor the moved parts, and make sure there's no
> GC> change anywhere else. To me, the lack of such "anchoring" is the
> GC> biggest drawback of 'meld', so I was excited to see that it's been
> GC> added to git-diff. Or excited to discover that it's always been there
> GC> but I hadn't noticed it. Anyway, it was pretty exciting.
> 
>  Sorry, I can't get excited because I still don't see how/why/when would I
> use it. Can you produce some useful output using it with the diff above? Or
> does it need a different kind of change to really show its usefulness?

This:
  git show --color-moved  f84e4c59
is a classic (though small) example of why I'd found "anchoring" so
useful in the past. If I "anchor" the first line in each moved block,
I can see that the move is pure. Then I can un-anchor them to see
that the un-moved part didn't change, either. Of course, this two-
step process requires intense attention to keep the moved and unmoved
parts clear in your mind so you can be sure you didn't miss anything.
It's cumbersome, but better than nothing, and I had come to depend
on it.

However, now that I understand that '--color-moved' actually does
highlight pure moves distinctly, I think it's so much better than
tedious, error-prone, manual anchoring that I no longer have a use
case for anchoring at all.

>  Anyhow, I've got enough excitement with the discovery of zebras in Git for
> one day, so I'm not complaining.

I still can't see why they called it "zebra". To me that suggests
alternating single lines in contrasting colors. But now that I've seen
its power, by whatever name, I'm not complaining, either. I'm so glad
you brought it up here. This will certainly save me five minutes per
week, so it's worth 21 hours:
  https://xkcd.com/1205/