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

Jonathan Nieder [off-list ref] writes:

Junio C Hamano wrote:

quoted

Jonathan Nieder [off-list ref] writes:

quoted

quoted

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.