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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan Nieder <jrnieder@xxxxxxxxx> writes:

> Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@xxxxxxxxx> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux