On Tue, Mar 2, 2010 at 1:43 AM, Michael Witten <mfwitten@xxxxxxxxx> wrote: >> By the way, the default should be 'always', not >> 'auto', to be consistent with GNU tools, and to be backwards >> compatible with the old --color behavior. > > Well, I've got: > > GNU grep 2.5.4 > > and the default for a plain `--color' seems to be `auto', whereby > colorization is turned on when stdout is attached to a tty capable > of color, but turned off otherwise: Sorry, that was my mistake about GNU grep. However, GNU ls (coreutils 7.4) defaults to 'always'. So, GNU tools are not consistent in this regard. Furthermore, the current behavior of all git tools is to make --color turn on color always, so I imagine you would have to make an extremely compelling argument to break backwards compatibility. I'll add that this behavior makes the most sense, since most folks who use color have done `git config color.ui auto'. This is why no one have created this patch until now. The [=<when>] part is nice, but the git config infrastructure usually obviates the need for --color=auto. > Firstly, note that GNU understands a wide set of option arguments: > > 1: always , yes , force > 0: never , no , none > 2: auto , tty , if-tty I guess this is okay, but I don't see a need for it. If we allow these other synonyms, then we'll have to support them forever. I say just stick with always/never/auto for now, and we could add the others later if there's a big demand. > In my opinion, Git grep should follow GNU grep's conventions, not > only to be consistent, but also because they are better. It is more important to be consistent with the other git tools, so that is why --color is a synonym for --color=always. -- 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