Re: What happened to "git status --color=(always|auto|never)"?

> > 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.