On 05/15/2013 02:09 PM, Matthieu Moy wrote: > Most users seem to like having colors enabled, and colors can help > beginners to understand the output of some commands (e.g. notice > immediately the boundary between commits in the output of "git log"). > > Many tutorials tell the users to set color.ui=auto as a very first step. > These tutorials would benefit from skiping > s/skiping/skipping/ > this step and starting the > real Git manipualtions earlier. > s/manipualtions/manipulations/ > 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. > s/prefered/preferred/ > 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). > > A transition period with Git emitting a warning when color.ui is unset > would be possible, but the discomfort of having the warning seems > superior to the benefit: users may be surprised by the change, but not > harmed by it. > > 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. > > Signed-off-by: Matthieu Moy <Matthieu.Moy@xxxxxxx> > --- >>> I'd love to see this by default, yes. Maybe a 2.0 change? >>> >>> If people agree that this is a good change, would we need a transition >>> plan? I'd say no, as there is no real backward incompatibility involved. >>> People who dislike colors can already set color.ui=false, and seeing >>> colors can hardly harm them, just temporarily reduce the comfort for >>> them. >> >> I vote for this. It's the first thing I do in any setup, even the ones >> that are note mine. I've also seen it in basically all the tutorials, >> even before setting user.name/email. >> >> I also don't see the point of a transition plan. > > OK, then let's try turning the discussion into code. > > 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 `always` if you want all output not intended for machine > - consumption to use color, to `true` or `auto` if you want such > - output to use color when written to the terminal, or to `false` or > - `never` if you prefer Git commands not to use color unless enabled > - explicitly with some other configuration or the `--color` option. > + 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. > > column.ui:: > Specify whether supported commands should output in columns. > diff --git a/color.c b/color.c > index e8e2681..f672885 100644 > --- a/color.c > +++ b/color.c > @@ -1,7 +1,7 @@ > #include "cache.h" > #include "color.h" > > -static int git_use_color_default = 0; > +static int git_use_color_default = GIT_COLOR_AUTO; > int color_stdout_is_tty = -1; > > /* > With the typos above fixed: Reviewed and supported-by: Stefano Lattarini <stefano.lattarini@xxxxxxxxx> Thanks, Stefano -- 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