Junio C Hamano <gitster@xxxxxxxxx> writes: > 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" I disagree: I do not know anyone who would be really harmed by colors (and such users would most likely have a terminal configured without colors I guess), so although I can imagine some people feeling less comfortable, disabling colors can be deferred to much later in the learning process. When I teach Git to students (a relatively short tutorial), I currently ask them to type a ~/.gitconfig containing color.ui=auto before anything else. If this was the default, I would skip this completely from the beginner-oriented doc, and I would mention color.ui=never only to people complaining about colors. It's really about _skipping_ the color-related stuff from the newbie docs, not about reverting them. Also, as my message points out, with "disabled by default", many people do not know that it is possible to have it, hence won't google for anything related to colors. There's no symmetry either here: with colors enabled by default, people will know that Git can use colors. >> 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? We've lived without this for years, so I'd say it can wait untill Git 2.0. It may give a "Wow" effect to some users when upgrading ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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