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

> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> 
> > 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").
> 
> > 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.
> 
> > 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?