On Tue, Oct 03, 2017 at 11:25:44AM +0900, Junio C Hamano wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
> > Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
> >
> >> Yet another alternative would be to treat color.ui=always as a
> >> deprecated synonym for color.ui=auto. I think that's my preferred
> >> fix.
> >
> > It is mine, too. And I do not think color.ui=absolutely-always for
> > those who want to keep the current behaviour is unneeded.
>
> Having said that, I do not mind solving what 136c8c8b ("color: check
> color.ui in git_default_config()", 2017-07-13) tried to do in a
> different way. If 4c7f1819b that made even plumbing to default to
> auto was wrong (because plumbing did not pay attention to color.ui
> so people could not override that 'auto' default), we can partially
> revert 4c7f1819 ("make color.ui default to 'auto'", 2013-06-10) to
> make the default 'auto' not apply to plumbing.
>
> In any case, I think the first step may be to revert 136c8c8b from
> both 'master' and 2.14.x. These alternative solutions can come on
> top.
>
> Thoughts?
I'd prefer not to revert. I think setting any of the color config to
"always" in an on-disk file is basically a broken config. It was
exacerbated by 4c7f1819b, but it was already broken for scripts that
call "git log" or "git diff", or even just something as simple as piping
those programs on the command line.
The two reasonable paths forward to me are:
1. Do nothing. Putting "color.ui = always" in your on-disk config is a
bad idea, and the right fix is to stop doing it.
2. Make "always" a synonym for "auto". This has the advantage over (1)
that you can't shoot yourself in the foot with it (so the expanded
foot-shooting capabilities of 4c7f1819b don't matter). The
disadvantage is that you can no longer do:
git -c color.ui=always foo >not-a-tty
to ask for color in all sub-programs of "foo". I have no idea if
anybody cares. I came up with that example in 4c7f1819b as the most
plausible reason somebody might actually care about "always", but
I've never used it myself.
And there _is_ a way to get the same thing, which is:
GIT_PAGER_IN_USE=1 git foo >not-a-tty
I.e., stay in "auto" but make the claim that "auto" really ought to
be showing color because the output is going to be consumed
eventually by a human. While it looks a bit funny in my made-up
example above (because the variables says "pager" but we're not
actually piping to a pager directly), I think this is the most
plausible reason that an actual program might want to override the
auto-color decision.
-Peff
