summaryrefslogtreecommitdiff
path: root/color.h
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2011-08-18 05:04:23 (GMT)
committerJunio C Hamano <gitster@pobox.com>2011-08-19 22:51:34 (GMT)
commitdaa0c3d9717624a62ce669252be832db12658ec0 (patch)
tree523e3e1d6c1d94bff9632b5e8f3da8a2d3799a18 /color.h
parente269eb7946d0a4ba6a4e175133b5479446ac04a5 (diff)
downloadgit-daa0c3d9717624a62ce669252be832db12658ec0.zip
git-daa0c3d9717624a62ce669252be832db12658ec0.tar.gz
git-daa0c3d9717624a62ce669252be832db12658ec0.tar.bz2
color: delay auto-color decision until point of use
When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'color.h')
-rw-r--r--color.h11
1 files changed, 11 insertions, 0 deletions
diff --git a/color.h b/color.h
index a190a25..b413e0e 100644
--- a/color.h
+++ b/color.h
@@ -49,6 +49,16 @@ struct strbuf;
#define GIT_COLOR_NIL "NIL"
/*
+ * The first three are chosen to match common usage in the code, and what is
+ * returned from git_config_colorbool. The "auto" value can be returned from
+ * config_colorbool, and will be converted by want_color() into either 0 or 1.
+ */
+#define GIT_COLOR_UNKNOWN -1
+#define GIT_COLOR_NEVER 0
+#define GIT_COLOR_ALWAYS 1
+#define GIT_COLOR_AUTO 2
+
+/*
* This variable stores the value of color.ui
*/
extern int git_use_color_default;
@@ -69,6 +79,7 @@ extern int color_stdout_is_tty;
int git_color_default_config(const char *var, const char *value, void *cb);
int git_config_colorbool(const char *var, const char *value);
+int want_color(int var);
void color_parse(const char *value, const char *var, char *dst);
void color_parse_mem(const char *value, int len, const char *var, char *dst);
__attribute__((format (printf, 3, 4)))