Thread (17 messages) 17 messages, 5 authors, 2016-06-15

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

From: Mark Lodato <hidden>
Date: 2016-06-15 22:48:23

On Tue, Mar 2, 2010 at 1:43 AM, Michael Witten [off-list ref] wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help