On Sat, Jan 05, 2008 at 12:01:51AM -0800, Junio C Hamano wrote: > 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 Right. My contention is that I think such people will be in the minority (though obviously I have no numbers to back it up, and nobody else is participating in this thread). > 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. 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." Period. There is no concern for the implementation detail of the diff machinery. > "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. I don't see that distinction as relevant. Diffs are diffs, whether you look at them with a small viewport or the whole thing. Would you expect "git diff -- file1 file2" to have different display options than "git diff -- file"? > 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." And yes, that's not exactly what config.txt says that color.interactive does; but I think that is probably worth fixing. > picker. To others, it is counterintuitive if color.diff had any > effect to what "git add -i" did. Then why does it affect what "git log" does? Why does it affect what "git reflog" does? Why does the documentation for color.diff say "use colors in patch" without any reference to specific programs? > 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. I think this is equally confusing. A user who sets color.diff will see color diffs from all porcelains _except_ "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). > 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. 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. I.e., "set color.interactive to true and color.interactive-diff to false" versus "set color.interactive to true, but then for every type of diff colorization, set the color for it in color.interactive.* to false". I think the extra knob is not a problem; it is simply a matter of defaulting the knobs based on other knobs. The rules for knobs interacting may seem complex, but I think we can DWIM. E.g., given config options: - color - color.diff - color.interactive - color.interactive.diff The rules for "git add -i" diff coloring would be: (1) if color.interactive.diff is set to TRUE/FALSE, use that (2) otherwise, if color.interactive is set to TRUE/FALSE, use that (3) otherwise, if color.diff is set to TRUE/FALSE, use that (4) otherwise, if color is set to TRUE/FALSE, use that IOW, even though we _have_ all of those knobs, users which don't want to fine-tune can just use the higher-level knobs. Those that want to can negate the higher level with lower level knobs. It's flexible, and it's easy to tell users "just do 'git config color true'." > Admittedly, it's more work. Of course. ;) But I am willing to implement what I said above if you agree that it is sensible. -Peff - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
