Jeff King [off-list ref] writes:
But he doesn't have to care about that. He cares only that "color.diff"
means "diffs are displayed in color." And "color.interactive" means
"interactive menus are displayed in color."
...
quoted
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
But he didn't. He said "git menus should be monochrome."
Who said anything about "interactive is limited to interactive
menus" anywhere? That is where we differ and what you do not
seem to be getting. I am talking about color.interactive that
controls the whole user experience of interacting with "add -i".
Moreover, this doesn't allow "I always want color in diffs,
but I don't want menu coloring" which is the very thing I have
been trying to accomplish (but yes, I can do that by
individually setting color.interactive.* to plain).
As you said earlier you may also be minority, but yes the color
pallette would help you do that.
I fail to see how this is less confusing than just adding a separate
interactive-diff knob, since you are asking them to individually set
each color preference to plain.
What I am aiming at in longer term is to simplify things this way:
* Users are categorized broadly into two groups. The ones who
like colours and the ones who don't want colours at all.
color.git would control this (with backward compatibility
options per command such as color.diff and
color.interactive);
* Minorities who want to disable colours for particular parts
of the UI have enough knobs to tweak in the form of palettes.
By definition this needs to address "particular parts", so
"color.$command.$context" variables (e.g. color.diff.new,
color.interactive.new; if somebody really really wants to
have different settings between diff/show/log, that person
could add color.{show,log}.new as well) are needed if we want
to do this.
E.g., given
config options:
...
quoted
Admittedly, it's more work.
Of course. ;) But I am willing to implement what I said above if you
agree that it is sensible.
I think we share the ultimate goal of introducing higher level
knobs and our difference is just about minor details of how to
get there and what the intermediate levels look like.
I am trying to avoid introducing new intermediate level knobs
(e.g. color.log vs color.diff), as it is enough to disable or in
general change the way particular parts of the UI is coloured by
palette setting that specifically states which part of the UI is
tweaked (e.g. color.interactive.prompt).
On Sat, Jan 05, 2008 at 01:28:25AM -0800, Junio C Hamano wrote:
Who said anything about "interactive is limited to interactive
menus" anywhere? That is where we differ and what you do not
seem to be getting. I am talking about color.interactive that
controls the whole user experience of interacting with "add -i".
I did, just now. I am "getting" it just fine, but am trying to propose
an equally valid, and IMHO more useful, semantic for
"color.interactive." (which btw, is a horrible name if you truly mean
"the behavior of git add -i" since there are _other_ interactive
commands. Why doesn't it turn on color for git-rebase -i?).
What I am aiming at in longer term is to simplify things this way:
* Users are categorized broadly into two groups. The ones who
like colours and the ones who don't want colours at all.
color.git would control this (with backward compatibility
options per command such as color.diff and
color.interactive);
OK, that makes sense. But I disagree somewhat with the phrase "backward
compatibility."
* Minorities who want to disable colours for particular parts
of the UI have enough knobs to tweak in the form of palettes.
They do, but those knobs are a pain to use. Why are we making it so hard
for them when we _already_ have the nice knobs for them to use. IOW, for
these users, git after this change will be _more_ annoying to use. Not
to mention that we must keep those other knobs around for historical
reasons for some amount of time.
Why not just add the higher-level knob and leave the existing ones
(using the priority scheme I mentioned in my last mail)?
By definition this needs to address "particular parts", so
"color.$command.$context" variables (e.g. color.diff.new,
color.interactive.new; if somebody really really wants to
have different settings between diff/show/log, that person
could add color.{show,log}.new as well) are needed if we want
to do this.
Sure. Though like you said previously, I think in 99% of cases, nobody
is going to set these to something exotic; they're going to set them all
ot their custom colors, or all to "plain". In which case, we are just
making work for them by not providing "color.show = false".
I am trying to avoid introducing new intermediate level knobs
(e.g. color.log vs color.diff), as it is enough to disable or in
general change the way particular parts of the UI is coloured by
palette setting that specifically states which part of the UI is
tweaked (e.g. color.interactive.prompt).
It is "enough" but I don't think it is the sensible goal. I respect your
desire to keep knobs to a minimum. But I think the fact that we can
split these color knobs into "dead simple, color = true" and "advanced,
super-picky color options" in the documentation makes it less of an
issue.
Anyway, almost none of this is pre-1.5.4. The one thing which is, IMHO,
is the semantics of color.interactive (since it has not yet been
released, this is the best time to set it). I will summarize my stance,
and you can do what you will. Beyond that, this discussion has already
taken way more time than this change is worth.
My opinion is that color.diff should be respected in "git-add -i"
regardless of color.interactive because:
- the color.diff setting controls diffs in all porcelain parts of git
(diff, log, show, reflog)
- parts of diffs are the same as diffs. Thus, hunks should in
general be treated like diffs for presentation.
- splitting color by functionality (i.e., diff versus menus) is
therefore more consistent with the rest of git than splitting it by
program ("git add -i" versus "git diff")
- I also happen to think that users are more likely to find "split by
functionality" useful, but neither of us has relevant data
(except that you seemed to indicate that's what you would find more
useful, and that's what I find more useful. So it's 2-0, and clearly
statistically significant :) ).
So if you are swayed by that, then please apply my previous patch, and
consider the documentation patch below. And if not, let me know and I
will begin changing my color.interactive.* config. :)
-- >8 --
Clarify color.interactive documentation
There are two possible confusions with the color.interactive
description:
1. the short name "interactive" implies that it covers all
interactive commands; let's explicitly make it so, even
though there are no other interactive commands which
currently use it
2. Not all parts of "git add --interactive" are controlled
by color.interactive (specifically, the diffs require
tweaking color.diff). So let's clarify that it applies
only to displays and prompts.
Signed-off-by: Jeff King <redacted>
---
Documentation/config.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e1eaee9..8907e16 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -406,7 +406,8 @@ color.diff.<slot>::
in color.branch.<slot>.
color.interactive::
- When set to `always`, always use colors in `git add --interactive`.
+ When set to `always`, always use colors for interactive prompts
+ and displays (such as those used by "git add --interactive").
When false (or `never`), never. When set to `true` or `auto`, use
colors only when the output is to the terminal. Defaults to false.
--
1.5.4.rc2.1125.ga305e-dirty