Re: [PATCH] add--interactive: allow diff colors without interactive colors

Jeff King [off-list ref] writes:

Let's assume that we don't want to add another color.interactive-diff
knob (though that is an option). That means that we have to tie the
colorization either to color.interactive or to color.diff. Right now we
subdivide it by command, so that the coloring of interactive diffs is
tied to color.interactive[1]. What I am proposing is to divide it by
_functionality_, so that by saying color.diff you mean "I like color
diffs, no matter where they are." And by saying color.interactive, you
mean "I like color interactive menus, no matter where they are." I think
it is much more likely that users will find that division useful. And
it's something we already do, since color.diff is respected not just by
git-diff, but by diffs produced by all programs, including the git-log
family.

I think I understood that part.  What I was saying was that it
is equally valid for other people to say "I like to interact
with 'git add -i' without colours because coloured output
distracts me when I have to think, even though I usually want to
view the whole diff in colours."  So yes, color.interactive-diff
is an option to give more flexibility, but no I do not think
that's a good flexibility.  I'd prefer a single "color.git"
environment that rules all, which is far simpler to explain and
configure.  Either you use colour for all your interaction with
git, or you live in black-and-white world.

[1]: Actually, we currently tie interactive diff coloring to "diff &&
interactive" which is even less useful. If I turn on color.interactive,
I still don't get colored diffs. But if I turn on color.diff, then
git-diff starts producing colored diffs. So you really can't represent
all choices, and I think the subdivision I outlined makes more sense (at
least it does to me).

And my point was that I doubt the change is such a big
improvement, certainly not in the way your justification
claimed, _even though I agree_ that the current "diff &&
interactive" way may not be something many people would want (by
the way, it happens to cover my preference, but that only means
I am a minority).  Neither covers all cases, and as I said, I do
not think more flexibility to cover all cases is necessarily a
good thing to shoot for.

Also there is another confusion factor we haven't discussed.

To an end user, the fact that "git add -p" shows diff using the
underlying "git diff" machinery does not matter.  That's just an
implementation detail.  "git diff" shows the whole diff at once
while "git add -p" shows it hunk by hunk.  It is clear they are
doing different things to the end user.  If he told "git add -p"
to be monochrome, he has every right to expect the part to pick
hunks to also stay monochrome.  To people who know the internal
implementation, it might be natural to expect the color.diff
configuration variable to affect the colouring of the hunk
picker.  To others, it is counterintuitive if color.diff had any
effect to what "git add -i" did.

That being said, all of those knobs _are_ confusing. In my case, I like
color. I just don't like the colors that color.interactive provides, so
I don't want to use them.  However, you can tune that quite a bit by
changing color.interactive.* (and just choosing "plain" for things you
don't want marked).

Yes, I 100% agree with you that they are confusing, and being to
able to futz with color.interactive.* palette would probably
alleviate the need to have color.{diff,interactive,status,etc}.

... Of course that still doesn't allow you to have
_different_ color settings between the diffs of git-diff and those of
git-add--interactive. But then, my point is that I don't think sane
users want that. They either want diffs colored or they don't, no matter
what command is producing them.

That point I would agree with you but only 70%.  No sane user
would want deleted lines in red in "git diff" output and in
purple in hunk picker.  But I think it is reasonable to want to
view them in monochrome while in hunk picker (by setting
color.*.old to plain) but in red in normal diff output.

Perhaps a saner alternative would be:

 * When color.interactive tells to use color, all interaction
   with "add -i" will be in color.  There is no need to have
   both color.diff and color.interactive set.

 * When color.interactive tells not to use color, everything
   including the diff output will be monochrome.  What you have
   in color.diff does not matter.

 * We could allow color.interactive.* pallete to have elements
   that are parallel to color.diff.* palette to be used while
   showing the colored diff.  But this would be a low priority
   because (1) a custom setting to anything but "plain" does not
   make much practical sense, as it is just introducing needless
   inconsistency between "git diff" and the hunk picker, and (2)
   custom setting to "plain" would be used by people who like
   colored "git add -i" prompts but not colored hunk picker,
   which would be a minority.

The point of the third item is that you enable color.interactive
and set diff related entries of color.interactive.* palette to
plain, if you want some color while interacting with "add -i"
but do not like colored hunk picker.  This would parallel the
way you can selectively enable coloring in "git diff" output,
where you enable color.diff and set metainfo color to plain if
you want some color in diff output but do not like colored
metainfo.

Admittedly, it's more work.