git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthieu Moy <Matthieu.Moy@imag.fr>
To: git@vger.kernel.org, gitster@pobox.com
Cc: Matthieu Moy <Matthieu.Moy@imag.fr>
Subject: [PATCH] make color.ui default to 'auto'
Date: Wed, 15 May 2013 14:09:17 +0200	[thread overview]
Message-ID: <1368619757-10402-1-git-send-email-Matthieu.Moy@imag.fr> (raw)
In-Reply-To: <vpq61yky2zp.fsf_-_@grenoble-inp.fr>

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 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).

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@imag.fr>
---
> > 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;
 
 /*
-- 
1.8.3.rc1.313.geb32591.dirty

  parent reply	other threads:[~2013-05-15 12:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-15  6:23 is this a bug of git-diff? eric liou
2013-05-15  6:43 ` Antoine Pelisse
     [not found]   ` <CABwUO_Wyq34S=CwbLeAqmzaFLxORkvGEvrjUzMXjkJdE1jnbhA@mail.gmail.com>
2013-05-15  7:10     ` Antoine Pelisse
2013-05-15  9:34       ` Matthieu Moy
2013-05-15  9:50         ` John Keeping
2013-05-15 10:03           ` Default for color.ui (was Re: is this a bug of git-diff?) Matthieu Moy
2013-05-15 10:37             ` Felipe Contreras
2013-05-15 12:09             ` Matthieu Moy [this message]
2013-05-15 12:59               ` [PATCH] make color.ui default to 'auto' Johan Herland
2013-05-15 13:21                 ` [PATCH v2] " Matthieu Moy
2013-05-15 16:09                   ` Junio C Hamano
2013-05-15 16:52                     ` Matthieu Moy
2013-05-15 17:00                       ` [PATCH 1/2] config: refactor management of color.ui's default value Matthieu Moy
2013-05-15 17:00                         ` [PATCH 2/2 v4] make color.ui default to 'auto' Matthieu Moy
2013-05-15 17:30                       ` [PATCH v2] " Junio C Hamano
2013-05-15 13:20               ` [PATCH] " Stefano Lattarini
2013-05-15 14:24                 ` [PATCH v3] " Matthieu Moy
2013-05-15 15:42               ` [PATCH] " Junio C Hamano
2013-05-15 16:27                 ` Matthieu Moy
2013-05-15 17:34                   ` Junio C Hamano
2013-05-15 17:56                     ` Matthieu Moy
2013-05-15 18:08                       ` Junio C Hamano
2013-05-15 18:21                         ` Matthieu Moy
2013-05-15 18:32                           ` Junio C Hamano
2013-05-15 19:41                             ` Felipe Contreras
2013-05-15 16:43                 ` John Keeping
2013-05-15 10:31           ` is this a bug of git-diff? Mike Hommey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1368619757-10402-1-git-send-email-Matthieu.Moy@imag.fr \
    --to=matthieu.moy@imag.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).