Re: [PATCH] make color.ui default to 'auto'
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 15, 2013, 15:42 UTC
- Message-ID
- <7vy5bgckr4.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <1368619757-10402-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
Show 9 quoted lines
> 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.
Show 20 quoted lines
> 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?
[Footnote]
*1* Unless you have some statistical fact to demonstrate that beginners who prefer colours are of lessor intelligence than those who do not, that is.
*2* It unnecessarily muddies the water to bring up "which is majority?". A poll might reveal more people prefer monochrome, but in that case, either we keep the default monochrome *and* fix the tutorial not to suggest auto, or we stick to the recommendation to use auto colouring. In other words, I see this change as merely making the code in line with the spirit of the documentation.