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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 10, 2017, 12:51 UTC
Message-ID: <xmqqfuarp3mt.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20171010102509.e7ucbyon6ka6722l@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 12 quoted lines

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

Show 5 quoted lines

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