Jeff King <p...@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.
