On Fri, Jan 04, 2008 at 04:20:09PM -0800, Junio C Hamano wrote: > Although I would agree with what this patch does, I think you > are contradicting with yourself in the above justification. > Some users may want to color "git diff" output but not > interaction with "git add -i", and that's also "just one without > the other", but you just tied them together, only differently, > and "seems unlikely" is a rather weak excuse. Then let me state it another way that I think makes a better argument. You have two knobs, color.interactive and color.diff, controlling menu-coloring of git-add--interactive and controlling colorization of git-diff output. Now we have a third thing that may be colorized: diff output of git-add--interactive. 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. [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). > The justification should instead be: having more independent > knobs is not necessarily better. The user should not have to > tweak too many knobs. > > In the longer term, I think we should try reducing the number of > knobs by giving "color.git" that allows you to pretend as if all > of the "color.interactive", "color.diff", "color.status", > "color.someothercolorizedcommand" are all set. I do not think > being able to control the use of colors per command is giving > much other than confusion to the user. I'm not sure I agree with that; my problem here is that I _want_ to turn a knob, but the functionality is tied to another knob. IOW, reducing the number of knobs is going to make it worse. 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). 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 may not be so easy with the current structure of the config > reader, though. I don't think it's hard; the client code for the colors checks a "color_foo" knob. It would just check "color_foo || color_all". -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
