summaryrefslogtreecommitdiff
path: root/color.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2017-07-13 15:07:03 (GMT)
committerJunio C Hamano <gitster@pobox.com>2017-07-13 19:42:51 (GMT)
commit136c8c8b8fa39f1315713248473dececf20f8fe7 (patch)
tree10e919202e04d085253e0ad2a5e8e228b3a01c94 /color.c
parentab7ded34d6a9a5d4c8bf073cb9627b8054f430cf (diff)
downloadgit-136c8c8b8fa39f1315713248473dececf20f8fe7.zip
git-136c8c8b8fa39f1315713248473dececf20f8fe7.tar.gz
git-136c8c8b8fa39f1315713248473dececf20f8fe7.tar.bz2
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 'color.c')
-rw-r--r--color.c8
1 files changed, 0 insertions, 8 deletions
diff --git a/color.c b/color.c
index 31b6207..7aa8b07 100644
--- a/color.c
+++ b/color.c
@@ -361,14 +361,6 @@ int git_color_config(const char *var, const char *value, void *cb)
return 0;
}
-int git_color_default_config(const char *var, const char *value, void *cb)
-{
- if (git_color_config(var, value, cb) < 0)
- return -1;
-
- return git_default_config(var, value, cb);
-}
-
void color_print_strbuf(FILE *fp, const char *color, const struct strbuf *sb)
{
if (*color)