Re: What happened to "git status --color=(always|auto|never)"?
- Date: Tue, 10 Oct 2017 21:51:38 +0900
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: What happened to "git status --color=(always|auto|never)"?
Jeff King <peff@xxxxxxxx> 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
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.