diff options
author | Jeff King <peff@peff.net> | 2017-10-03 09:46:06 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2017-10-04 11:35:30 +0900 |
commit | 6be4595edb8e5b616c6e8b9fbc78b0f831fa2a87 (patch) | |
tree | 6d48467cbf96f7326d7465d2f65538145713b239 /color.c | |
parent | 0c88bf50502e2be7d7d8965052d77bbf08e1d519 (diff) | |
download | git-6be4595edb8e5b616c6e8b9fbc78b0f831fa2a87.tar.gz |
color: make "always" the same as "auto" in config
It can be handy to use `--color=always` (or it's synonym
`--color`) on the command-line to convince a command to
produce color even if it's stdout isn't going to the
terminal or a pager.
What's less clear is whether it makes sense to set config
variables like color.ui to `always`. For a one-shot like:
git -c color.ui=always ...
it's potentially useful (especially if the command doesn't
directly support the `--color` option). But setting `always`
in your on-disk config is much muddier, as you may be
surprised when piped commands generate colors (and send them
to whatever is consuming the pipe downstream).
Some people have done this anyway, because:
1. The documentation for color.ui makes it sound like
using `always` is a good idea, when you almost
certainly want `auto`.
2. Traditionally not every command (and especially not
plumbing) respected color.ui in the first place. So
the confusion came up less frequently than it might
have.
The situation changed in 136c8c8b8f (color: check color.ui
in git_default_config(), 2017-07-13), which negated point
(2): now scripts using only plumbing commands (like
add-interactive) are broken by this setting.
That commit was fixing real issues (e.g., by making
`color.ui=never` work, since `auto` is the default), so we
don't want to just revert it. We could turn `always` into a
noop in plumbing commands, but that creates a hard-to-explain
inconsistency between the plumbing and other commands.
Instead, let's just turn `always` into `auto` for all config.
This does break the "one-shot" config shown above, but again,
we're probably better to have simple and consistent rules than
to try to special-case command-line config.
There is one place where `always` should retain its meaning:
on the command line, `--color=always` should continue to be
the same as `--color`, overriding any isatty checks. Since the
command-line parser also depends on git_config_colorbool(), we
can use the existence of the "var" string to deterine whether
we are serving the command-line or the config.
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.c | 2 |
1 files changed, 1 insertions, 1 deletions
@@ -308,7 +308,7 @@ int git_config_colorbool(const char *var, const char *value) if (!strcasecmp(value, "never")) return 0; if (!strcasecmp(value, "always")) - return 1; + return var ? GIT_COLOR_AUTO : 1; if (!strcasecmp(value, "auto")) return GIT_COLOR_AUTO; } |