From: Jeff King <p...@peff.net>
An earlier patch downgraded "always" that comes via the ui.color
configuration variable to "auto", in order to work around an
unfortunate regression to "git add -i".
That "fix" however regressed other third-party tools that depend on
"git -c color.ui=always cmd" as the way to defeat any end-user
configuration and force coloured output from git subcommand, even
when the output does not go to a terminal.
It is a bit ugly to treat "-c color.ui=always" from the command line
differently from a definition that comes from on-disk configuration
files, but it is a moral equivalent of "--color=always" option given
to the subcommand from the command line, i.e. a signal that tells us
that the script writer knows what s/he is doing. So let's take that
route to unbreak this case while defeating a (now declared to be)
misguided color.ui that is set to always in the configuration file.
NEEDS-SIGN-OFF-BY: Jeff King <p...@peff.net>
Signed-off-by: Junio C Hamano <gits...@pobox.com>
---
color.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/color.c b/color.c
index 17e2713f96..5b06c76bdc 100644
--- a/color.c
+++ b/color.c
@@ -307,8 +307,21 @@ int git_config_colorbool(const char *var, const char
*value)
if (value) {
if (!strcasecmp(value, "never"))
return 0;
- if (!strcasecmp(value, "always"))
- return var ? GIT_COLOR_AUTO : 1;
+ if (!strcasecmp(value, "always")) {
+ /*
+ * Command-line options always respect "always".
+ * Likewise for "-c" config on the command-line.
+ */
+ if (!var ||
+ current_config_scope() == CONFIG_SCOPE_CMDLINE)
+ return 1;
+
+ /*
+ * Otherwise, we're looking at on-disk config;
+ * downgrade to auto.
+ */
+ return GIT_COLOR_AUTO;
+ }
if (!strcasecmp(value, "auto"))
return GIT_COLOR_AUTO;
}
--
2.15.0-rc1-151-g44fe2f342f
