Re: [PATCH 4/5] grep: Colorize filename, line number, and separator

[Mark Lodato <lodatom@gmail.com>]

On Tue, Mar 2, 2010 at 1:43 AM, Michael Witten <mfwitten@gmail.com> 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.