Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 12, 2017, 06:15 UTC
Message-ID: <xmqq1sm828pi.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20171012054049.GF155740@aiede.mtv.corp.google.com>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 22 quoted lines

> Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>>> Should we document this special case treatment of color.* in -c
>>> somewhere?  E.g.
>>
>> Perhaps, although I'd save that until we actually add the new option
>> to "git" potty, which hasn't happened yet, if I were thinking about
>> adding some text like that.  Also I'd call that --default-color=always
>> or something like that, to avoid having to answer: what are the
>> differences between these two --color thing in the following?
>>
>>     git --color=foo cmd --color=bar
>
> I agree that the color.status text in the example doc is unfortunate.
> But the surprising thing I found when writing that doc is that
> color.status ("git status", "git commit --dry-run") and
> color.interactive are the only items that needed it (aside from
> color.ui that needed it for those two).  All the other commands that
> use color already accept
>
> 	git cmd --color=bar

Ahh, I take it that you mean by "it" (in "needed it") the "git potty" option, not a "--color=<what>" option individual "git cmd" takes? If so, then it makes sense to say "that's another way to spell --color=always from the command line".

We need to be able to answer "why does '-c color.ui=always' work only from the command line?", but I doubt we want to actively encourage the use of it, though, so I dunno.