Hi, Jeff King wrote: > On Tue, Oct 10, 2017 at 09:51:38PM +0900, Junio C Hamano wrote:
>> I think the right fix to the original problem (you cannot remove >> auto-color from the plumbing) is to stop paying attention to color >> configuration from the default config. I wonder if something like >> this would work? >> >> - Initialize color.c::git_use_color_default to GIT_COLOR_UNKNOWN; >> >> - When git_color_config() is called, and if git_use_color_default >> is still GIT_COLOR_UNKNOWN, set it to GIT_COLOR_AUTO (regardless >> of the variable git_color_config() is called for). >> >> - In color.c::want_color(), when git_use_color_default is used, >> notice if it is GIT_COLOR_UNKNOWN and behave as if it is >> GIT_COLOR_NEVER. >> >> Then we make sure that git_color_config() is never called by any >> plumbing command. The fact it is (ever) called can be taken as a >> clue that we are running a Porcelain (hence we transition from >> UNKNOWN to AUTO), so we'd get the desirable "no default color for >> plumbing, auto color for Porcelain", I would think. > > Yes, I think that's the simplest way to implement the "plumbing should > never do color without a command-line option" scheme. > > I do wonder if people would end up seeing some corner cases as > regressions, though. Right now "diff-tree" _does_ color the output by > default, and it would stop doing so under your scheme. That's the right > thing to do by the plumbing/porcelain distinction, but users with > scripts that use diff-tree (or other plumbing) to generate user-visible > output may unexpectedly lose their color, until the calling script is > fixed to add back in a --color option[1]. I think it's better for the calling script to be fixed to use "git diff", since it is producing output for the sake of the user instead of for machine parsing. That way, the script gets the benefit of other changes like --decorate automatically. So I don't see that as a regression. Where I worry is about commands where the line between porcelain and plumbing blur, like "git log --format=raw". I actually still prefer the approach where "color.ui=always" becomes impossible to express in config and each command takes a --color option. If we want to be extra fancy, we could make git take a --color option instead of requiring each command to do it. To support existing scripts, we could treat "-c color.ui=always" as a historical synonym for --color=always, either temporarily or indefinitely. Making it clear that this is only there for historical reasons would make it less likely that other options make the same mistake in the future. Thanks, Jonathan
