Re: [PATCH] make color.ui default to 'auto'

On Wed, May 15, 2013 at 08:42:39AM -0700, Junio C Hamano wrote:

Matthieu Moy [off-list ref] writes:

quoted

Many tutorials tell the users to set color.ui=auto as a very first step.
These tutorials would benefit from skiping this step and starting the
real Git manipualtions 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 prefered 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).

The above two paragraphs do not make a good justification [*1*].
The former can just as easily websearch for "enable colours in git"
as the latter would for "disable" in order to avoid having to live
with distraction while they may have preferred monochrome.

The train of thought that is a sufficient justification for this
change is "Our document and third-party tutorials often start with
setting color.ui=auto configuration." leading to "Our recommendation
is to enable colour on terminals." which in turn leading to "Why is
our default monochrome, against our own recommendation?".  Saying
anything more, like who are the majority or how easily the default
can be overridden, is unnecessary, I think [*2*].

As this is purely a UI thing, and since daa0c3d97176 (color: delay
auto-color decision until point of use, 2011-08-17), the logic to
decide when "auto colouring" is triggered is centrary controlled
(hence it is much less likely than before that color.ui=auto could
misfire when it shouldn't), I agree that this does not even deserve
a warning. You could even sell it as a pure bugfix ("we recommend
users to use auto colouring but we did not set it up for users").

quoted

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.

Good.

quoted

I'm starting to wonder why we didn't do this earlier ;-).

 Documentation/config.txt | 11 ++++++-----
 color.c                  |  2 +-
 2 files changed, 7 insertions(+), 6 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 `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.

OK, so this is planned for 2.0?

I would vote for just considering this a bugfix as you say above and
therefore not worthy of any special treatment, so it should end up in
whatever the next release is after it hits master.

The changes that are being held back for 2.0 change how commands operate
and we don't provide any overrides for those; this is just a cosmetic
change to the default output format.