Junio C Hamano [off-list ref] writes:
Matthieu Moy [off-list ref] writes:
quoted
diff --git a/builtin/config.c b/builtin/config.c
index 000d27c..ecfceca 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -316,7 +316,7 @@ static void get_color(const char *def_color)
static int get_colorbool_found;
static int get_diff_color_found;
-static int get_color_ui_found;
+static int get_color_ui_found = GIT_COLOR_AUTO;
It is curious to notice that we have these three and only one is
initialized to the new default value, while the other two get -1
at the beginning of get_colorbool().
Right. The meaning of the _found suffix is clear for the first two, but
not the last.
I wonder if it would be cleaner to statically initialize all three
to -1 here, drop the assignment of -1 to two of them from the
beginning of get_colorbool(), and then have a final fallback inside
the want_color() call itself, i.e.
I've left the assignments within the function (I like the initialisation
right before usage, I don't have to worry about how many times the
function is called then), but I've added a patch that initializes
get_color_ui_found to -1 like the others, and does essentially this:
get_colorbool_found = want_color(get_colorbool_found < 0
? GIT_COLOR_AUTO
: get_colorbool_found);
Except I've made it a separate if statement. Then PATCH 2/2 is really
crystal clear.
Reroll comming, with an improved commit message that should adress the
points in the other message.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of "git log").
Many tutorials tell the users to set color.ui=auto as a very first step,
which tend to indicate that color.ui=none is not the recommanded value,
hence should not be the default.
These tutorials would benefit from skipping this step and starting the
real Git manipulations earlier. Other beginners do not know about
color.ui=auto, and may not discover it by themselves, hence live with
black&white outputs while they may have preferred colors.
A few people (e.g. color-blind) prefer having no colors, but they can
easily set color.ui=never for this (and googling "disable colors in git"
already tells them how to do so), but this needs not occupy space in
beginner-oriented documentations.
A transition period with Git emitting a warning when color.ui is unset
would be possible, but the discomfort of having the warning seems
superior to the benefit: users may be surprised by the change, but not
harmed by it.
The default value is changed, and the documentation is reworded to
mention "color.ui=false" first, since the primary use of color.ui after
this change is to disable colors, not to enable it.
Signed-off-by: Matthieu Moy <redacted>
---
Adapted after PATCH 1/2, and commit message updated.
Documentation/config.txt | 11 ++++++-----
builtin/config.c | 2 +-
color.c | 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1009bfc..97550be 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -913,11 +913,12 @@ color.ui::
as `color.diff` and `color.grep` that control the use of color
per command family. Its scope will expand as more commands learn
configuration to set a default for the `--color` option. Set it
- to `always` if you want all output not intended for machine
- consumption to use color, to `true` or `auto` if you want such
- output to use color when written to the terminal, or to `false` or
- `never` if you prefer Git commands not to use color unless enabled
- explicitly with some other configuration or the `--color` option.
+ to `false` or `never` if you prefer Git commands not to use
+ color unless enabled explicitly with some other configuration
+ or the `--color` option. Set it to `always` if you want all
+ output not intended for machine consumption to use color, to
+ `true` or `auto` (this is the default since Git 2.0) if you
+ want such output to use color when written to the terminal.
column.ui::
Specify whether supported commands should output in columns.
diff --git a/builtin/config.c b/builtin/config.c
index 171bad7..4010c43 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -347,7 +347,7 @@ static int get_colorbool(int print)
if (get_colorbool_found < 0)
/* default value if none found in config */
- get_colorbool_found = 0;
+ get_colorbool_found = GIT_COLOR_AUTO;
get_colorbool_found = want_color(get_colorbool_found);
diff --git a/color.c b/color.c
index e8e2681..f672885 100644
--- a/color.c
+++ b/color.c
@@ -1,7 +1,7 @@
#include "cache.h"
#include "color.h"
-static int git_use_color_default = 0;
+static int git_use_color_default = GIT_COLOR_AUTO;
int color_stdout_is_tty = -1;
/*
--
1.8.3.rc1.315.g4602f33
The meaning of get_colorbool_found and get_diff_color_found is "the
config value if found, and -1 otherwise", but get_color_ui_found had a
slightly different meaning, as it has the value 0 (which corresponds to
the default value from the user point of view) when color.ui is unset.
Make get_color_ui_found default to -1, and make it explicit that 0 is the
default value when nothing else is found.
Signed-off-by: Matthieu Moy <redacted>
---
So, this is new, as suggested by Junio.
builtin/config.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/builtin/config.c b/builtin/config.c
index 000d27c..171bad7 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -333,6 +333,7 @@ static int get_colorbool(int print)
{
get_colorbool_found = -1;
get_diff_color_found = -1;
+ get_color_ui_found = -1;
git_config_with_options(git_get_colorbool_config, NULL,
given_config_file, given_config_blob,
respect_includes);@@ -344,6 +345,10 @@ static int get_colorbool(int print)
get_colorbool_found = get_color_ui_found;
}
+ if (get_colorbool_found < 0)
+ /* default value if none found in config */
+ get_colorbool_found = 0;
+
get_colorbool_found = want_color(get_colorbool_found);
if (print) {--
1.8.3.rc1.315.g4602f33