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.