Matthieu Moy <Matthieu.Moy@xxxxxxx> 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?
[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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html