Jonathan Nieder <jrnie...@gmail.com> writes:
> Junio C Hamano wrote:
>> Jonathan Nieder <jrnie...@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.
