summaryrefslogtreecommitdiff
path: root/config.c
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-07-13 11:07:03 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-07-13 12:42:51 -0700
commit136c8c8b8fa39f1315713248473dececf20f8fe7 (patch)
tree10e919202e04d085253e0ad2a5e8e228b3a01c94 /config.c
parentref-filter: pass ref_format struct to atom parsers (diff)
downloadtgif-136c8c8b8fa39f1315713248473dececf20f8fe7.tar.xz
color: check color.ui in git_default_config()
Back in prehistoric times, our decision on whether or not to show color by default relied on using a config callback that either did or didn't load color config like color.diff. When we introduced color.ui, we put it in the same boat: commands had to manually respect it by using git_color_config() or its git_color_default_config() convenience wrapper. But in 4c7f1819b (make color.ui default to 'auto', 2013-06-10), that changed. Since then, we default color.ui to auto in all programs, meaning that even plumbing commands like "git diff-tree --pretty" might colorize the output. Nobody seems to have complained in the intervening years, presumably because the "is stdout a tty" check does a good job of catching the right cases. But that leaves an interesting curiosity: color.ui defaults to auto even in plumbing, but you can't actually _disable_ the color via config. So if you really hate color and set "color.ui" to false, diff-tree will still show color (but porcelain like git-diff won't). Nobody noticed that either, probably because very few people disable color. One could argue that the plumbing should _always_ disable color unless an explicit --color option is given on the command line. But in practice, this creates a lot of complications for scripts which do want plumbing to show user-visible output. They can't just pass "--color" blindly; they need to check the user's config and decide what to send. Given that nobody has complained about the current behavior, let's assume it's a good path, and follow it to its conclusion: supporting color.ui everywhere. Note that you can create havoc by setting color.ui=always in your config, but that's more or less already the case. We could disallow it entirely, but it is handy for one-offs like: git -c color.ui=always foo >not-a-tty when "foo" does not take a --color option itself. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'config.c')
-rw-r--r--config.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/config.c b/config.c
index a9356c1383..bc290e7563 100644
--- a/config.c
+++ b/config.c
@@ -16,6 +16,7 @@
#include "string-list.h"
#include "utf8.h"
#include "dir.h"
+#include "color.h"
struct config_source {
struct config_source *prev;
@@ -1350,6 +1351,9 @@ int git_default_config(const char *var, const char *value, void *dummy)
if (starts_with(var, "advice."))
return git_default_advice_config(var, value);
+ if (git_color_config(var, value, dummy) < 0)
+ return -1;
+
if (!strcmp(var, "pager.color") || !strcmp(var, "color.pager")) {
pager_use_color = git_config_bool(var,value);
return 0;