Jeff King <peff@xxxxxxxx> writes: > Users with color.diff set to true/auto will not see color in > "git add -i" unless they also set color.interactive. > > However, some users may want just one without the other, so > there's no reason to tie them together. > > Note that there is now no way to have color on for "git > diff" but not for diffs from "git add -i"; such a > configuration seems unlikely, though. 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. 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. That may not be so easy with the current structure of the config reader, though. - 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
