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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> :( I was worried that this might hit some third-party scripts.
> ...
> All that said, should we revisit the decision from 6be4595edb? The two
> code changes we could make are:
>
>   1. Adding a "--color" option to "git status". Commit 0c88bf5050
>      (provide --color option for all ref-filter users, 2017-10-03) from
>      that same series shows some prior art.
>
>      This is a clean solution, but it does mean that scripts have to
>      adapt (and would potentially need to care about which Git version
>      they're relying on).

If we view that "always" issue is a regression, then this is not a
"solution".  It is a part of an ideal world where we never allowed
"always" as a value for color.ui, which is not the world we live in.

>   2. Re-allow "color.always" config from the command-line. It's actually
>      on-disk config that we want to downgrade, but I wanted to avoid
>      making complicated rules about how the config would behave in
>      different scopes. The patch for this would look something like the
>      one below.

Yuck, ugly.  The code is simple (thanks to the "who ordered it?"
thing), but the behaviour is rather embarrassing to explain.

>   3. Revert the original series, and revisit the original "respect
>      color.ui via porcelain" commit which broke add--interactive in
>      v2.14.2 (136c8c8b8fa).

Which one do you mean is "the original series"?  The one that made
plumbing to pay attention to the color config?  I think it would be
the cleanest "solution" in the world we live in, but the series (and
the follow-on changes that started assuming that config_default
reads the color config) have a rather large footprint and it will be
quite painful to vet the result.

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.