{"thread":{"id":"33822","subject":"is this a bug of git-diff?","startedAt":"2013-05-15T06:23:07Z","lastAt":"2013-05-15T19:41:03Z","messageCount":27,"participants":["eric liou","Antoine Pelisse","Matthieu Moy","John Keeping","Felipe Contreras","Mike Hommey","Johan Herland","Stefano Lattarini","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"217410","messageId":"CABwUO_X8oTzuJh8+v3Oqca2W4ht-cQRNGQ+a1DbEruq5jY+vgA@mail.gmail.com","threadId":"33822","inReplyTo":null,"subject":"is this a bug of git-diff?","fromName":"eric liou","fromEmail":"accwuya@gmail.com","sentAt":"2013-05-15T06:23:07Z","receivedAt":"2013-05-15T06:23:07Z","isPatch":false,"sender":{"key":"accwuya@gmail.com","avatar":null},"body":"The output of git-diff is different from my expectation.\nIt may skip some lines of context.\nFor the case of the diff result attached here, a blank line and a line\nwith a leading slash is skipped.\n\nPlease check out the attached files for details.\n\nThanks.\n\n\nindex 1ef2bf5..ef2206b 100644\n--- a/t.c\n+++ b/t.c\n@@ -4,5 +4,6 @@ int a = 1;\n * 1\n * 2\n * 3\n+ * added\n */\n\n\nint a = 1;\n\n/*\n * 1\n * 2\n * 3\n * added\n */\n \n\nint a = 1;\n\n/*\n * 1\n * 2\n * 3\n */\n "},{"id":"217412","messageId":"CALWbr2z338CJgavC9sVGffHSoqr0Sb9nCsr4LKURDYpkOog2TQ@mail.gmail.com","threadId":"33822","inReplyTo":"CABwUO_X8oTzuJh8+v3Oqca2W4ht-cQRNGQ+a1DbEruq5jY+vgA@mail.gmail.com","subject":"Re: is this a bug of git-diff?","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-05-15T06:43:40Z","receivedAt":"2013-05-15T06:43:40Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Wed, May 15, 2013 at 8:23 AM, eric liou wrote:\n> The output of git-diff is different from my expectation.\n> It may skip some lines of context.\n\ngit-diff is using a default of 3 lines of context above and below the changes.\nIn your example, there is only two lines of context below the change,\nso only two lines are displayed.\nAbove the change, three lines are displayed, as expected. That's why\nthe blank line and leading slash line are not displayed.\nYou can change the number of context lines by invoking git-diff with -U.\n\nHope that helps,\nAntoine\n"},{"id":"217417","messageId":"CALWbr2z2jB53=2UsEneqymU2peiL4OW9Tyace_8BN3=1gA9jNg@mail.gmail.com","threadId":"33822","inReplyTo":"CABwUO_Wyq34S=CwbLeAqmzaFLxORkvGEvrjUzMXjkJdE1jnbhA@mail.gmail.com","subject":"Re: is this a bug of git-diff?","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-05-15T07:10:11Z","receivedAt":"2013-05-15T07:10:11Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Wed, May 15, 2013 at 8:52 AM, eric liou wrote:\n> Thank you for the quick reply.\n> But this line is not correct: \"@@ -4,5 +4,6 @@ int a = 1;\"\n\nOh OK, I see.\nGit tries to name the function where the changes take place. This is\npurely informative.\nIn your example, you don't have any function so of course the\ninformation is not very helpful.\n\nTypically it will look like the following, helping the reader by\ngiving the function name:\n\n@@ -591,6 +609,14 @@ int cmd_grep(int argc, const char **argv, const\nchar *prefix)\n paths[1] = NULL;\n }\n\n+ if (!use_index) {\n+ if (cached)\n+ die(\"--cached cannot be used with --no-index.\");\n+ if (list.nr)\n+ die(\"--no-index cannot be used with revs.\");\n+ return !grep_directory(&opt, paths);\n+ }\n+\n if (!list.nr) {\n if (!cached)\n setup_work_tree();\n"},{"id":"217419","messageId":"vpqhai4y4b2.fsf@grenoble-inp.fr","threadId":"33822","inReplyTo":"CALWbr2z2jB53=2UsEneqymU2peiL4OW9Tyace_8BN3=1gA9jNg@mail.gmail.com","subject":"Re: is this a bug of git-diff?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-05-15T09:34:41Z","receivedAt":"2013-05-15T09:34:41Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Antoine Pelisse writes:\n\n> On Wed, May 15, 2013 at 8:52 AM, eric liou wrote:\n>> Thank you for the quick reply.\n>> But this line is not correct: \"@@ -4,5 +4,6 @@ int a = 1;\"\n\nAntoine's answer is correct. In addition, I'd say that you may want to\nenable color in the output to make it clearer (the @@ ... @@ part would\nbe colored, but not the function name):\n\n git config --global color.ui auto\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"217421","messageId":"20130515095025.GV2299@serenity.lan","threadId":"33822","inReplyTo":"vpqhai4y4b2.fsf@grenoble-inp.fr","subject":"Re: is this a bug of git-diff?","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-15T09:50:25Z","receivedAt":"2013-05-15T09:50:25Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote:\n> Antoine's answer is correct. In addition, I'd say that you may want to\n> enable color in the output to make it clearer (the @@ ... @@ part would\n> be colored, but not the function name):\n> \n> git config --global color.ui auto\n\nI wonder if that should be the default. I've advised a lot of people to\nturn it on and it seems to me that a user is much more likely to go\nlooking for a \"turn color off\" option than realise that color is an\noption at all.\n"},{"id":"217422","messageId":"vpq61yky2zp.fsf_-_@grenoble-inp.fr","threadId":"33822","inReplyTo":"20130515095025.GV2299@serenity.lan","subject":"Default for color.ui (was Re: is this a bug of git-diff?)","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-05-15T10:03:06Z","receivedAt":"2013-05-15T10:03:06Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"John Keeping writes:\n\n> I wonder if that should be the default. I've advised a lot of people to\n> turn it on and it seems to me that a user is much more likely to go\n> looking for a \"turn color off\" option than realise that color is an\n> option at all.\n\nI'd love to see this by default, yes. Maybe a 2.0 change?\n\nIf people agree that this is a good change, would we need a transition\nplan? I'd say no, as there is no real backward incompatibility involved.\nPeople who dislike colors can already set color.ui=false, and seeing\ncolors can hardly harm them, just temporarily reduce the comfort for\nthem.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"217425","messageId":"20130515103132.GA19425@glandium.org","threadId":"33822","inReplyTo":"20130515095025.GV2299@serenity.lan","subject":"Re: is this a bug of git-diff?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2013-05-15T10:31:32Z","receivedAt":"2013-05-15T10:31:32Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Wed, May 15, 2013 at 10:50:25AM +0100, John Keeping wrote:\n> On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote:\n> > Antoine's answer is correct. In addition, I'd say that you may want to\n> > enable color in the output to make it clearer (the @@ ... @@ part would\n> > be colored, but not the function name):\n> > \n> > git config --global color.ui auto\n> \n> I wonder if that should be the default. I've advised a lot of people to\n> turn it on and it seems to me that a user is much more likely to go\n> looking for a \"turn color off\" option than realise that color is an\n> option at all.\n\n+1. My settings have been there for so long that I thought it was the\ndefault.\n\nMike\n"},{"id":"217423","messageId":"CAMP44s2PAzoDEJ3WP0WQet8QiXs4qq83U8JUdLx+VthcC7nbUQ@mail.gmail.com","threadId":"33822","inReplyTo":"vpq61yky2zp.fsf_-_@grenoble-inp.fr","subject":"Re: Default for color.ui (was Re: is this a bug of git-diff?)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-15T10:37:11Z","receivedAt":"2013-05-15T10:37:11Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 15, 2013 at 5:03 AM, Matthieu Moy\n wrote:\n> John Keeping writes:\n>\n>> I wonder if that should be the default. I've advised a lot of people to\n>> turn it on and it seems to me that a user is much more likely to go\n>> looking for a \"turn color off\" option than realise that color is an\n>> option at all.\n>\n> I'd love to see this by default, yes. Maybe a 2.0 change?\n>\n> If people agree that this is a good change, would we need a transition\n> plan? I'd say no, as there is no real backward incompatibility involved.\n> People who dislike colors can already set color.ui=false, and seeing\n> colors can hardly harm them, just temporarily reduce the comfort for\n> them.\n\nI vote for this. It's the first thing I do in any setup, even the ones\nthat are note mine. I've also seen it in basically all the tutorials,\neven before setting user.name/email.\n\nI also don't see the point of a transition plan.\n\n-- \nFelipe Contreras\n"},{"id":"217428","messageId":"1368619757-10402-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"33822","inReplyTo":"vpq61yky2zp.fsf_-_@grenoble-inp.fr","subject":"[PATCH] make color.ui default to 'auto'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2013-05-15T12:09:17Z","receivedAt":"2013-05-15T12:09:17Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Most users seem to like having colors enabled, and colors can help\nbeginners to understand the output of some commands (e.g. notice\nimmediately the boundary between commits in the output of \"git log\").\n\nMany tutorials tell the users to set color.ui=auto as a very first step.\nThese tutorials would benefit from skiping this step and starting the\nreal Git manipualtions earlier. Other beginners do not know about\ncolor.ui=auto, and may not discover it by themselves, hence live with\nblack&white outputs while they may have prefered colors.\n\nA few people (e.g. color-blind) prefer having no colors, but they can\neasily set color.ui=never for this (and googling \"disable colors in git\"\nalready tells them how to do so).\n\nA transition period with Git emitting a warning when color.ui is unset\nwould be possible, but the discomfort of having the warning seems\nsuperior to the benefit: users may be surprised by the change, but not\nharmed by it.\n\nThe default value is changed, and the documentation is reworded to\nmention \"color.ui=false\" first, since the primary use of color.ui after\nthis change is to disable colors, not to enable it.\n\nSigned-off-by: Matthieu Moy \n---\n> > I'd love to see this by default, yes. Maybe a 2.0 change?\n> >\n> > If people agree that this is a good change, would we need a transition\n> > plan? I'd say no, as there is no real backward incompatibility involved.\n> > People who dislike colors can already set color.ui=false, and seeing\n> > colors can hardly harm them, just temporarily reduce the comfort for\n> > them.\n> \n> I vote for this. It's the first thing I do in any setup, even the ones\n> that are note mine. I've also seen it in basically all the tutorials,\n> even before setting user.name/email.\n> \n> I also don't see the point of a transition plan.\n\nOK, then let's try turning the discussion into code.\n\nI'm starting to wonder why we didn't do this earlier ;-).\n\n Documentation/config.txt | 11 ++++++-----\n color.c | 2 +-\n 2 files changed, 7 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 1009bfc..97550be 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -913,11 +913,12 @@ color.ui::\n \tas `color.diff` and `color.grep` that control the use of color\n \tper command family. Its scope will expand as more commands learn\n \tconfiguration to set a default for the `--color` option. Set it\n-\tto `always` if you want all output not intended for machine\n-\tconsumption to use color, to `true` or `auto` if you want such\n-\toutput to use color when written to the terminal, or to `false` or\n-\t`never` if you prefer Git commands not to use color unless enabled\n-\texplicitly with some other configuration or the `--color` option.\n+\tto `false` or `never` if you prefer Git commands not to use\n+\tcolor unless enabled explicitly with some other configuration\n+\tor the `--color` option. Set it to `always` if you want all\n+\toutput not intended for machine consumption to use color, to\n+\t`true` or `auto` (this is the default since Git 2.0) if you\n+\twant such output to use color when written to the terminal.\n \n column.ui::\n \tSpecify whether supported commands should output in columns.\ndiff --git a/color.c b/color.c\nindex e8e2681..f672885 100644\n--- a/color.c\n+++ b/color.c\n@@ -1,7 +1,7 @@\n #include \"cache.h\"\n #include \"color.h\"\n \n-static int git_use_color_default = 0;\n+static int git_use_color_default = GIT_COLOR_AUTO;\n int color_stdout_is_tty = -1;\n \n /*\n-- \n1.8.3.rc1.313.geb32591.dirty\n"},{"id":"217431","messageId":"CALKQrgdVf_rfsLu1NnXGk+LCTV34T-4doJ+2yyi69ZER8vTAfg@mail.gmail.com","threadId":"33822","inReplyTo":"1368619757-10402-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH] make color.ui default to 'auto'","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2013-05-15T12:59:29Z","receivedAt":"2013-05-15T12:59:29Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wed, May 15, 2013 at 2:09 PM, Matthieu Moy wrote:\n> Signed-off-by: Matthieu Moy \n\nReviewed and supported-by: Johan Herland \n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"217433","messageId":"51938B90.8040004@gmail.com","threadId":"33822","inReplyTo":"1368619757-10402-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH] make color.ui default to 'auto'","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2013-05-15T13:20:16Z","receivedAt":"2013-05-15T13:20:16Z","isPatch":true,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"On 05/15/2013 02:09 PM, Matthieu Moy wrote:\n> Most users seem to like having colors enabled, and colors can help\n> beginners to understand the output of some commands (e.g. notice\n> immediately the boundary between commits in the output of \"git log\").\n> \n> Many tutorials tell the users to set color.ui=auto as a very first step.\n> These tutorials would benefit from skiping\n>\ns/skiping/skipping/\n\n> this step and starting the\n> real Git manipualtions earlier.\n>\ns/manipualtions/manipulations/\n\n> Other beginners do not know about\n> color.ui=auto, and may not discover it by themselves, hence live with\n> black&white outputs while they may have prefered colors.\n>\ns/prefered/preferred/\n\n> A few people (e.g. color-blind) prefer having no colors, but they can\n> easily set color.ui=never for this (and googling \"disable colors in git\"\n> already tells them how to do so).\n> \n> A transition period with Git emitting a warning when color.ui is unset\n> would be possible, but the discomfort of having the warning seems\n> superior to the benefit: users may be surprised by the change, but not\n> harmed by it.\n> \n> The default value is changed, and the documentation is reworded to\n> mention \"color.ui=false\" first, since the primary use of color.ui after\n> this change is to disable colors, not to enable it.\n> \n> Signed-off-by: Matthieu Moy \n> ---\n>>> I'd love to see this by default, yes. Maybe a 2.0 change?\n>>>\n>>> If people agree that this is a good change, would we need a transition\n>>> plan? I'd say no, as there is no real backward incompatibility involved.\n>>> People who dislike colors can already set color.ui=false, and seeing\n>>> colors can hardly harm them, just temporarily reduce the comfort for\n>>> them.\n>>\n>> I vote for this. It's the first thing I do in any setup, even the ones\n>> that are note mine. I've also seen it in basically all the tutorials,\n>> even before setting user.name/email.\n>>\n>> I also don't see the point of a transition plan.\n> \n> OK, then let's try turning the discussion into code.\n> \n> I'm starting to wonder why we didn't do this earlier ;-).\n> \n> Documentation/config.txt | 11 ++++++-----\n> color.c | 2 +-\n> 2 files changed, 7 insertions(+), 6 deletions(-)\n> \n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 1009bfc..97550be 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -913,11 +913,12 @@ color.ui::\n> \tas `color.diff` and `color.grep` that control the use of color\n> \tper command family. Its scope will expand as more commands learn\n> \tconfiguration to set a default for the `--color` option. Set it\n> -\tto `always` if you want all output not intended for machine\n> -\tconsumption to use color, to `true` or `auto` if you want such\n> -\toutput to use color when written to the terminal, or to `false` or\n> -\t`never` if you prefer Git commands not to use color unless enabled\n> -\texplicitly with some other configuration or the `--color` option.\n> +\tto `false` or `never` if you prefer Git commands not to use\n> +\tcolor unless enabled explicitly with some other configuration\n> +\tor the `--color` option. Set it to `always` if you want all\n> +\toutput not intended for machine consumption to use color, to\n> +\t`true` or `auto` (this is the default since Git 2.0) if you\n> +\twant such output to use color when written to the terminal.\n> \n> column.ui::\n> \tSpecify whether supported commands should output in columns.\n> diff --git a/color.c b/color.c\n> index e8e2681..f672885 100644\n> --- a/color.c\n> +++ b/color.c\n> @@ -1,7 +1,7 @@\n> #include \"cache.h\"\n> #include \"color.h\"\n> \n> -static int git_use_color_default = 0;\n> +static int git_use_color_default = GIT_COLOR_AUTO;\n> int color_stdout_is_tty = -1;\n> \n> /*\n>\nWith the typos above fixed:\n\n Reviewed and supported-by: Stefano Lattarini \n\nThanks,\n Stefano\n"},{"id":"217434","messageId":"1368624095-15738-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"33822","inReplyTo":"CALKQrgdVf_rfsLu1NnXGk+LCTV34T-4doJ+2yyi69ZER8vTAfg@mail.gmail.com","subject":"[PATCH v2] make color.ui default to 'auto'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2013-05-15T13:21:35Z","receivedAt":"2013-05-15T13:21:35Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Most users seem to like having colors enabled, and colors can help\nbeginners to understand the output of some commands (e.g. notice\nimmediately the boundary between commits in the output of \"git log\").\n\nMany tutorials tell the users to set color.ui=auto as a very first step.\nThese tutorials would benefit from skiping this step and starting the\nreal Git manipualtions earlier. Other beginners do not know about\ncolor.ui=auto, and may not discover it by themselves, hence live with\nblack&white outputs while they may have prefered colors.\n\nA few people (e.g. color-blind) prefer having no colors, but they can\neasily set color.ui=never for this (and googling \"disable colors in git\"\nalready tells them how to do so).\n\nA transition period with Git emitting a warning when color.ui is unset\nwould be possible, but the discomfort of having the warning seems\nsuperior to the benefit: users may be surprised by the change, but not\nharmed by it.\n\nThe default value is changed, and the documentation is reworded to\nmention \"color.ui=false\" first, since the primary use of color.ui after\nthis change is to disable colors, not to enable it.\n\nSigned-off-by: Matthieu Moy \n---\n> Reviewed and supported-by: Johan Herland \n\nApparently not well enough ;-).\n\nIn v1, \"git config --get-colorbool\" was not affected, hence \"git add\n-p\" wasn't colored. v2 fixes this.\n\n Documentation/config.txt | 11 ++++++-----\n builtin/config.c | 2 +-\n color.c | 2 +-\n 3 files changed, 8 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 1009bfc..97550be 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -913,11 +913,12 @@ color.ui::\n \tas `color.diff` and `color.grep` that control the use of color\n \tper command family. Its scope will expand as more commands learn\n \tconfiguration to set a default for the `--color` option. Set it\n-\tto `always` if you want all output not intended for machine\n-\tconsumption to use color, to `true` or `auto` if you want such\n-\toutput to use color when written to the terminal, or to `false` or\n-\t`never` if you prefer Git commands not to use color unless enabled\n-\texplicitly with some other configuration or the `--color` option.\n+\tto `false` or `never` if you prefer Git commands not to use\n+\tcolor unless enabled explicitly with some other configuration\n+\tor the `--color` option. Set it to `always` if you want all\n+\toutput not intended for machine consumption to use color, to\n+\t`true` or `auto` (this is the default since Git 2.0) if you\n+\twant such output to use color when written to the terminal.\n \n column.ui::\n \tSpecify whether supported commands should output in columns.\ndiff --git a/builtin/config.c b/builtin/config.c\nindex 000d27c..ecfceca 100644\n--- a/builtin/config.c\n+++ b/builtin/config.c\n@@ -316,7 +316,7 @@ static void get_color(const char *def_color)\n \n static int get_colorbool_found;\n static int get_diff_color_found;\n-static int get_color_ui_found;\n+static int get_color_ui_found = GIT_COLOR_AUTO;\n static int git_get_colorbool_config(const char *var, const char *value,\n \t\tvoid *cb)\n {\ndiff --git a/color.c b/color.c\nindex e8e2681..f672885 100644\n--- a/color.c\n+++ b/color.c\n@@ -1,7 +1,7 @@\n #include \"cache.h\"\n #include \"color.h\"\n \n-static int git_use_color_default = 0;\n+static int git_use_color_default = GIT_COLOR_AUTO;\n int color_stdout_is_tty = -1;\n \n /*\n-- \n1.8.3.rc1.314.g2261e40.dirty\n"},{"id":"217437","messageId":"1368627869-16539-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"33822","inReplyTo":"51938B90.8040004@gmail.com","subject":"[PATCH v3] make color.ui default to 'auto'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2013-05-15T14:24:29Z","receivedAt":"2013-05-15T14:24:29Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Most users seem to like having colors enabled, and colors can help\nbeginners to understand the output of some commands (e.g. notice\nimmediately the boundary between commits in the output of \"git log\").\n\nMany tutorials tell the users to set color.ui=auto as a very first step.\nThese tutorials would benefit from skipping this step and starting the\nreal Git manipulations earlier. Other beginners do not know about\ncolor.ui=auto, and may not discover it by themselves, hence live with\nblack&white outputs while they may have preferred colors.\n\nA few people (e.g. color-blind) prefer having no colors, but they can\neasily set color.ui=never for this (and googling \"disable colors in git\"\nalready tells them how to do so).\n\nA transition period with Git emitting a warning when color.ui is unset\nwould be possible, but the discomfort of having the warning seems\nsuperior to the benefit: users may be surprised by the change, but not\nharmed by it.\n\nThe default value is changed, and the documentation is reworded to\nmention \"color.ui=false\" first, since the primary use of color.ui after\nthis change is to disable colors, not to enable it.\n\nSigned-off-by: Matthieu Moy \n---\nv2 crossed Stefano's email with typos. v3 just fixes these typos in\nthe commit message.\n\n Documentation/config.txt | 11 ++++++-----\n builtin/config.c | 2 +-\n color.c | 2 +-\n 3 files changed, 8 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 1009bfc..97550be 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -913,11 +913,12 @@ color.ui::\n \tas `color.diff` and `color.grep` that control the use of color\n \tper command family. Its scope will expand as more commands learn\n \tconfiguration to set a default for the `--color` option. Set it\n-\tto `always` if you want all output not intended for machine\n-\tconsumption to use color, to `true` or `auto` if you want such\n-\toutput to use color when written to the terminal, or to `false` or\n-\t`never` if you prefer Git commands not to use color unless enabled\n-\texplicitly with some other configuration or the `--color` option.\n+\tto `false` or `never` if you prefer Git commands not to use\n+\tcolor unless enabled explicitly with some other configuration\n+\tor the `--color` option. Set it to `always` if you want all\n+\toutput not intended for machine consumption to use color, to\n+\t`true` or `auto` (this is the default since Git 2.0) if you\n+\twant such output to use color when written to the terminal.\n \n column.ui::\n \tSpecify whether supported commands should output in columns.\ndiff --git a/builtin/config.c b/builtin/config.c\nindex 000d27c..ecfceca 100644\n--- a/builtin/config.c\n+++ b/builtin/config.c\n@@ -316,7 +316,7 @@ static void get_color(const char *def_color)\n \n static int get_colorbool_found;\n static int get_diff_color_found;\n-static int get_color_ui_found;\n+static int get_color_ui_found = GIT_COLOR_AUTO;\n static int git_get_colorbool_config(const char *var, const char *value,\n \t\tvoid *cb)\n {\ndiff --git a/color.c b/color.c\nindex e8e2681..f672885 100644\n--- a/color.c\n+++ b/color.c\n@@ -1,7 +1,7 @@\n #include \"cache.h\"\n #include \"color.h\"\n \n-static int git_use_color_default = 0;\n+static int git_use_color_default = GIT_COLOR_AUTO;\n int color_stdout_is_tty = -1;\n \n /*\n-- \n1.8.3.rc1.314.g2261e40.dirty\n"},{"id":"217446","messageId":"7vy5bgckr4.fsf@alter.siamese.dyndns.org","threadId":"33822","inReplyTo":"1368619757-10402-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH] make color.ui default to 'auto'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-15T15:42:39Z","receivedAt":"2013-05-15T15:42:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Many tutorials tell the users to set color.ui=auto as a very first step.\n> These tutorials would benefit from skiping this step and starting the\n> real Git manipualtions earlier. Other beginners do not know about\n> color.ui=auto, and may not discover it by themselves, hence live with\n> black&white outputs while they may have prefered colors.\n>\n> A few people (e.g. color-blind) prefer having no colors, but they can\n> easily set color.ui=never for this (and googling \"disable colors in git\"\n> already tells them how to do so).\n\nThe above two paragraphs do not make a good justification [*1*].\nThe former can just as easily websearch for \"enable colours in git\"\nas the latter would for \"disable\" in order to avoid having to live\nwith distraction while they may have preferred monochrome.\n\nThe train of thought that is a sufficient justification for this\nchange is \"Our document and third-party tutorials often start with\nsetting color.ui=auto configuration.\" leading to \"Our recommendation\nis to enable colour on terminals.\" which in turn leading to \"Why is\nour default monochrome, against our own recommendation?\". Saying\nanything more, like who are the majority or how easily the default\ncan be overridden, is unnecessary, I think [*2*].\n\nAs this is purely a UI thing, and since daa0c3d97176 (color: delay\nauto-color decision until point of use, 2011-08-17), the logic to\ndecide when \"auto colouring\" is triggered is centrary controlled\n(hence it is much less likely than before that color.ui=auto could\nmisfire when it shouldn't), I agree that this does not even deserve\na warning. You could even sell it as a pure bugfix (\"we recommend\nusers to use auto colouring but we did not set it up for users\").\n\n> The default value is changed, and the documentation is reworded to\n> mention \"color.ui=false\" first, since the primary use of color.ui after\n> this change is to disable colors, not to enable it.\n\nGood.\n\n> I'm starting to wonder why we didn't do this earlier ;-).\n>\n> Documentation/config.txt | 11 ++++++-----\n> color.c | 2 +-\n> 2 files changed, 7 insertions(+), 6 deletions(-)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 1009bfc..97550be 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -913,11 +913,12 @@ color.ui::\n> \tas `color.diff` and `color.grep` that control the use of color\n> \tper command family. Its scope will expand as more commands learn\n> \tconfiguration to set a default for the `--color` option. Set it\n> +\tto `false` or `never` if you prefer Git commands not to use\n> +\tcolor unless enabled explicitly with some other configuration\n> +\tor the `--color` option. Set it to `always` if you want all\n> +\toutput not intended for machine consumption to use color, to\n> +\t`true` or `auto` (this is the default since Git 2.0) if you\n> +\twant such output to use color when written to the terminal.\n\nOK, so this is planned for 2.0?\n\n\n[Footnote]\n\n*1* Unless you have some statistical fact to demonstrate that\nbeginners who prefer colours are of lessor intelligence than\nthose who do not, that is.\n\n*2* It unnecessarily muddies the water to bring up \"which is\nmajority?\". A poll might reveal more people prefer monochrome, but\nin that case, either we keep the default monochrome *and* fix the\ntutorial not to suggest auto, or we stick to the recommendation to\nuse auto colouring. In other words, I see this change as merely\nmaking the code in line with the spirit of the documentation.\n"},{"id":"217448","messageId":"7vtxm4cjil.fsf@alter.siamese.dyndns.org","threadId":"33822","inReplyTo":"1368624095-15738-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH v2] make color.ui default to 'auto'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-15T16:09:22Z","receivedAt":"2013-05-15T16:09:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> diff --git a/builtin/config.c b/builtin/config.c\n> index 000d27c..ecfceca 100644\n> --- a/builtin/config.c\n> +++ b/builtin/config.c\n> @@ -316,7 +316,7 @@ static void get_color(const char *def_color)\n> \n> static int get_colorbool_found;\n> static int get_diff_color_found;\n> -static int get_color_ui_found;\n> +static int get_color_ui_found = GIT_COLOR_AUTO;\n\nIt is curious to notice that we have these three and only one is\ninitialized to the new default value, while the other two get -1\nat the beginning of get_colorbool().\n\nI wonder if it would be cleaner to statically initialize all three\nto -1 here, drop the assignment of -1 to two of them from the\nbeginning of get_colorbool(), and then have a final fallback inside\nthe want_color() call itself, i.e.\n\n\tget_colorbool_found = want_color(get_colorbool_found < 0\n \t\t\t\t? GIT_COLOR_AUTO\n : get_colorbool_found);\n\nso that it is clear that -1 consistently mean \"We haven't read any\nvalue from the configuration file for this variable\", instead of\nmaking get_color_ui_found mean slightly different thing (the value\nread from the configuration; GIT_COLOR_AUTO means we cannot tell if\nwe saw this variable or the user specified auto) from the other two\n(the value read from the configuration; -1 means we did not find\nany).\n"},{"id":"217449","messageId":"vpqhai4fbsn.fsf@grenoble-inp.fr","threadId":"33822","inReplyTo":"7vy5bgckr4.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] make color.ui default to 'auto'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-05-15T16:27:52Z","receivedAt":"2013-05-15T16:27:52Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> Many tutorials tell the users to set color.ui=auto as a very first step.\n>> These tutorials would benefit from skiping this step and starting the\n>> real Git manipualtions earlier. Other beginners do not know about\n>> color.ui=auto, and may not discover it by themselves, hence live with\n>> black&white outputs while they may have prefered colors.\n>>\n>> A few people (e.g. color-blind) prefer having no colors, but they can\n>> easily set color.ui=never for this (and googling \"disable colors in git\"\n>> already tells them how to do so).\n>\n> The above two paragraphs do not make a good justification [*1*].\n> The former can just as easily websearch for \"enable colours in git\"\n\nI disagree: I do not know anyone who would be really harmed by colors\n(and such users would most likely have a terminal configured without\ncolors I guess), so although I can imagine some people feeling less\ncomfortable, disabling colors can be deferred to much later in the\nlearning process.\n\nWhen I teach Git to students (a relatively short tutorial), I currently\nask them to type a ~/.gitconfig containing color.ui=auto before anything\nelse. If this was the default, I would skip this completely from the\nbeginner-oriented doc, and I would mention color.ui=never only to people\ncomplaining about colors. It's really about _skipping_ the color-related\nstuff from the newbie docs, not about reverting them.\n\nAlso, as my message points out, with \"disabled by default\", many people\ndo not know that it is possible to have it, hence won't google for\nanything related to colors. There's no symmetry either here: with colors\nenabled by default, people will know that Git can use colors.\n\n>> diff --git a/Documentation/config.txt b/Documentation/config.txt\n>> index 1009bfc..97550be 100644\n>> --- a/Documentation/config.txt\n>> +++ b/Documentation/config.txt\n>> @@ -913,11 +913,12 @@ color.ui::\n>> \tas `color.diff` and `color.grep` that control the use of color\n>> \tper command family. Its scope will expand as more commands learn\n>> \tconfiguration to set a default for the `--color` option. Set it\n>> +\tto `false` or `never` if you prefer Git commands not to use\n>> +\tcolor unless enabled explicitly with some other configuration\n>> +\tor the `--color` option. Set it to `always` if you want all\n>> +\toutput not intended for machine consumption to use color, to\n>> +\t`true` or `auto` (this is the default since Git 2.0) if you\n>> +\twant such output to use color when written to the terminal.\n>\n> OK, so this is planned for 2.0?\n\nWe've lived without this for years, so I'd say it can wait untill Git\n2.0. It may give a \"Wow\" effect to some users when upgrading ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"217450","messageId":"20130515164314.GW2299@serenity.lan","threadId":"33822","inReplyTo":"7vy5bgckr4.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] make color.ui default to 'auto'","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-15T16:43:14Z","receivedAt":"2013-05-15T16:43:14Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, May 15, 2013 at 08:42:39AM -0700, Junio C Hamano wrote:\n> Matthieu Moy writes:\n> \n> > Many tutorials tell the users to set color.ui=auto as a very first step.\n> > These tutorials would benefit from skiping this step and starting the\n> > real Git manipualtions earlier. Other beginners do not know about\n> > color.ui=auto, and may not discover it by themselves, hence live with\n> > black&white outputs while they may have prefered colors.\n> >\n> > A few people (e.g. color-blind) prefer having no colors, but they can\n> > easily set color.ui=never for this (and googling \"disable colors in git\"\n> > already tells them how to do so).\n> \n> The above two paragraphs do not make a good justification [*1*].\n> The former can just as easily websearch for \"enable colours in git\"\n> as the latter would for \"disable\" in order to avoid having to live\n> with distraction while they may have preferred monochrome.\n> \n> The train of thought that is a sufficient justification for this\n> change is \"Our document and third-party tutorials often start with\n> setting color.ui=auto configuration.\" leading to \"Our recommendation\n> is to enable colour on terminals.\" which in turn leading to \"Why is\n> our default monochrome, against our own recommendation?\". Saying\n> anything more, like who are the majority or how easily the default\n> can be overridden, is unnecessary, I think [*2*].\n> \n> As this is purely a UI thing, and since daa0c3d97176 (color: delay\n> auto-color decision until point of use, 2011-08-17), the logic to\n> decide when \"auto colouring\" is triggered is centrary controlled\n> (hence it is much less likely than before that color.ui=auto could\n> misfire when it shouldn't), I agree that this does not even deserve\n> a warning. You could even sell it as a pure bugfix (\"we recommend\n> users to use auto colouring but we did not set it up for users\").\n> \n> > The default value is changed, and the documentation is reworded to\n> > mention \"color.ui=false\" first, since the primary use of color.ui after\n> > this change is to disable colors, not to enable it.\n> \n> Good.\n> \n> > I'm starting to wonder why we didn't do this earlier ;-).\n> >\n> > Documentation/config.txt | 11 ++++++-----\n> > color.c | 2 +-\n> > 2 files changed, 7 insertions(+), 6 deletions(-)\n> >\n> > diff --git a/Documentation/config.txt b/Documentation/config.txt\n> > index 1009bfc..97550be 100644\n> > --- a/Documentation/config.txt\n> > +++ b/Documentation/config.txt\n> > @@ -913,11 +913,12 @@ color.ui::\n> > \tas `color.diff` and `color.grep` that control the use of color\n> > \tper command family. Its scope will expand as more commands learn\n> > \tconfiguration to set a default for the `--color` option. Set it\n> > +\tto `false` or `never` if you prefer Git commands not to use\n> > +\tcolor unless enabled explicitly with some other configuration\n> > +\tor the `--color` option. Set it to `always` if you want all\n> > +\toutput not intended for machine consumption to use color, to\n> > +\t`true` or `auto` (this is the default since Git 2.0) if you\n> > +\twant such output to use color when written to the terminal.\n> \n> OK, so this is planned for 2.0?\n\nI would vote for just considering this a bugfix as you say above and\ntherefore not worthy of any special treatment, so it should end up in\nwhatever the next release is after it hits master.\n\nThe changes that are being held back for 2.0 change how commands operate\nand we don't provide any overrides for those; this is just a cosmetic\nchange to the default output format.\n"},{"id":"217451","messageId":"vpq61ykfang.fsf@grenoble-inp.fr","threadId":"33822","inReplyTo":"7vtxm4cjil.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] make color.ui default to 'auto'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-05-15T16:52:35Z","receivedAt":"2013-05-15T16:52:35Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> diff --git a/builtin/config.c b/builtin/config.c\n>> index 000d27c..ecfceca 100644\n>> --- a/builtin/config.c\n>> +++ b/builtin/config.c\n>> @@ -316,7 +316,7 @@ static void get_color(const char *def_color)\n>> \n>> static int get_colorbool_found;\n>> static int get_diff_color_found;\n>> -static int get_color_ui_found;\n>> +static int get_color_ui_found = GIT_COLOR_AUTO;\n>\n> It is curious to notice that we have these three and only one is\n> initialized to the new default value, while the other two get -1\n> at the beginning of get_colorbool().\n\nRight. The meaning of the _found suffix is clear for the first two, but\nnot the last.\n\n> I wonder if it would be cleaner to statically initialize all three\n> to -1 here, drop the assignment of -1 to two of them from the\n> beginning of get_colorbool(), and then have a final fallback inside\n> the want_color() call itself, i.e.\n\nI've left the assignments within the function (I like the initialisation\nright before usage, I don't have to worry about how many times the\nfunction is called then), but I've added a patch that initializes\nget_color_ui_found to -1 like the others, and does essentially this:\n\n> \tget_colorbool_found = want_color(get_colorbool_found < 0\n> \t\t\t\t? GIT_COLOR_AUTO\n> : get_colorbool_found);\n\nExcept I've made it a separate if statement. Then PATCH 2/2 is really\ncrystal clear.\n\nReroll comming, with an improved commit message that should adress the\npoints in the other message.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"217453","messageId":"1368637256-22622-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"33822","inReplyTo":"vpq61ykfang.fsf@grenoble-inp.fr","subject":"[PATCH 1/2] config: refactor management of color.ui's default value","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2013-05-15T17:00:55Z","receivedAt":"2013-05-15T17:00:55Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"The meaning of get_colorbool_found and get_diff_color_found is \"the\nconfig value if found, and -1 otherwise\", but get_color_ui_found had a\nslightly different meaning, as it has the value 0 (which corresponds to\nthe default value from the user point of view) when color.ui is unset.\n\nMake get_color_ui_found default to -1, and make it explicit that 0 is the\ndefault value when nothing else is found.\n\nSigned-off-by: Matthieu Moy \n---\nSo, this is new, as suggested by Junio.\n\n builtin/config.c | 5 +++++\n 1 file changed, 5 insertions(+)\n\ndiff --git a/builtin/config.c b/builtin/config.c\nindex 000d27c..171bad7 100644\n--- a/builtin/config.c\n+++ b/builtin/config.c\n@@ -333,6 +333,7 @@ static int get_colorbool(int print)\n {\n \tget_colorbool_found = -1;\n \tget_diff_color_found = -1;\n+\tget_color_ui_found = -1;\n \tgit_config_with_options(git_get_colorbool_config, NULL,\n \t\t\t\tgiven_config_file, given_config_blob,\n \t\t\t\trespect_includes);\n@@ -344,6 +345,10 @@ static int get_colorbool(int print)\n \t\t\tget_colorbool_found = get_color_ui_found;\n \t}\n \n+\tif (get_colorbool_found < 0)\n+\t\t/* default value if none found in config */\n+\t\tget_colorbool_found = 0;\n+\n \tget_colorbool_found = want_color(get_colorbool_found);\n \n \tif (print) {\n-- \n1.8.3.rc1.315.g4602f33\n"},{"id":"217452","messageId":"1368637256-22622-2-git-send-email-Matthieu.Moy@imag.fr","threadId":"33822","inReplyTo":"1368637256-22622-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 2/2 v4] make color.ui default to 'auto'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2013-05-15T17:00:56Z","receivedAt":"2013-05-15T17:00:56Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Most users seem to like having colors enabled, and colors can help\nbeginners to understand the output of some commands (e.g. notice\nimmediately the boundary between commits in the output of \"git log\").\n\nMany tutorials tell the users to set color.ui=auto as a very first step,\nwhich tend to indicate that color.ui=none is not the recommanded value,\nhence should not be the default.\n\nThese tutorials would benefit from skipping this step and starting the\nreal Git manipulations earlier. Other beginners do not know about\ncolor.ui=auto, and may not discover it by themselves, hence live with\nblack&white outputs while they may have preferred colors.\n\nA few people (e.g. color-blind) prefer having no colors, but they can\neasily set color.ui=never for this (and googling \"disable colors in git\"\nalready tells them how to do so), but this needs not occupy space in\nbeginner-oriented documentations.\n\nA transition period with Git emitting a warning when color.ui is unset\nwould be possible, but the discomfort of having the warning seems\nsuperior to the benefit: users may be surprised by the change, but not\nharmed by it.\n\nThe default value is changed, and the documentation is reworded to\nmention \"color.ui=false\" first, since the primary use of color.ui after\nthis change is to disable colors, not to enable it.\n\nSigned-off-by: Matthieu Moy \n---\nAdapted after PATCH 1/2, and commit message updated.\n\n Documentation/config.txt | 11 ++++++-----\n builtin/config.c | 2 +-\n color.c | 2 +-\n 3 files changed, 8 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 1009bfc..97550be 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -913,11 +913,12 @@ color.ui::\n \tas `color.diff` and `color.grep` that control the use of color\n \tper command family. Its scope will expand as more commands learn\n \tconfiguration to set a default for the `--color` option. Set it\n-\tto `always` if you want all output not intended for machine\n-\tconsumption to use color, to `true` or `auto` if you want such\n-\toutput to use color when written to the terminal, or to `false` or\n-\t`never` if you prefer Git commands not to use color unless enabled\n-\texplicitly with some other configuration or the `--color` option.\n+\tto `false` or `never` if you prefer Git commands not to use\n+\tcolor unless enabled explicitly with some other configuration\n+\tor the `--color` option. Set it to `always` if you want all\n+\toutput not intended for machine consumption to use color, to\n+\t`true` or `auto` (this is the default since Git 2.0) if you\n+\twant such output to use color when written to the terminal.\n \n column.ui::\n \tSpecify whether supported commands should output in columns.\ndiff --git a/builtin/config.c b/builtin/config.c\nindex 171bad7..4010c43 100644\n--- a/builtin/config.c\n+++ b/builtin/config.c\n@@ -347,7 +347,7 @@ static int get_colorbool(int print)\n \n \tif (get_colorbool_found < 0)\n \t\t/* default value if none found in config */\n-\t\tget_colorbool_found = 0;\n+\t\tget_colorbool_found = GIT_COLOR_AUTO;\n \n \tget_colorbool_found = want_color(get_colorbool_found);\n \ndiff --git a/color.c b/color.c\nindex e8e2681..f672885 100644\n--- a/color.c\n+++ b/color.c\n@@ -1,7 +1,7 @@\n #include \"cache.h\"\n #include \"color.h\"\n \n-static int git_use_color_default = 0;\n+static int git_use_color_default = GIT_COLOR_AUTO;\n int color_stdout_is_tty = -1;\n \n /*\n-- \n1.8.3.rc1.315.g4602f33\n"},{"id":"217456","messageId":"7vd2sscfru.fsf@alter.siamese.dyndns.org","threadId":"33822","inReplyTo":"vpq61ykfang.fsf@grenoble-inp.fr","subject":"Re: [PATCH v2] make color.ui default to 'auto'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-15T17:30:13Z","receivedAt":"2013-05-15T17:30:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> Matthieu Moy writes:\n>>\n>>> diff --git a/builtin/config.c b/builtin/config.c\n>>> index 000d27c..ecfceca 100644\n>>> --- a/builtin/config.c\n>>> +++ b/builtin/config.c\n>>> @@ -316,7 +316,7 @@ static void get_color(const char *def_color)\n>>> \n>>> static int get_colorbool_found;\n>>> static int get_diff_color_found;\n>>> -static int get_color_ui_found;\n>>> +static int get_color_ui_found = GIT_COLOR_AUTO;\n>>\n>> It is curious to notice that we have these three and only one is\n>> initialized to the new default value, while the other two get -1\n>> at the beginning of get_colorbool().\n>\n> Right. The meaning of the _found suffix is clear for the first two, but\n> not the last.\n>\n>> I wonder if it would be cleaner to statically initialize all three\n>> to -1 here, drop the assignment of -1 to two of them from the\n>> beginning of get_colorbool(), and then have a final fallback inside\n>> the want_color() call itself, i.e.\n>\n> I've left the assignments within the function (I like the initialisation\n> right before usage, I don't have to worry about how many times the\n> function is called then), but I've added a patch that initializes\n> get_color_ui_found to -1 like the others, and does essentially this:\n>\n>> \tget_colorbool_found = want_color(get_colorbool_found < 0\n>> \t\t\t\t? GIT_COLOR_AUTO\n>> : get_colorbool_found);\n>\n> Except I've made it a separate if statement. Then PATCH 2/2 is really\n> crystal clear.\n\nYeah, sounds good.\n\n> Reroll comming, with an improved commit message that should adress the\n> points in the other message.\n\nHmm, I don't see much improvement in the message, though. It seems\nto talk about \"may not discover\", \"live with\", \"a few people\", and\n\"they can easily\", none of which should be there.\n"},{"id":"217458","messageId":"7v8v3gcfk1.fsf@alter.siamese.dyndns.org","threadId":"33822","inReplyTo":"vpqhai4fbsn.fsf@grenoble-inp.fr","subject":"Re: [PATCH] make color.ui default to 'auto'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-15T17:34:54Z","receivedAt":"2013-05-15T17:34:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n>> The above two paragraphs do not make a good justification [*1*].\n>> The former can just as easily websearch for \"enable colours in git\"\n>\n> I disagree: I do not know anyone who would be really harmed by colors\n> ...\n\nI actually am one of them (light cyan or green on white background\nwith small font is very hard to read for me), but I think you are\nmissing the entire point, which is not \"is anyone harmed?\"\n\nThis patch is not even about deciding if colored output should be\nthe default. That has already been decided by documentation for us\nlong time ago; the patch does not have to (and should not) argue for\nand justify why color is good. Our recommendation has been \"use\ncolor=auto\", and change of the in-code default is merely to make the\ndefault in line with that recommendation.\n"},{"id":"217461","messageId":"vpqwqr0azz7.fsf@grenoble-inp.fr","threadId":"33822","inReplyTo":"7v8v3gcfk1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] make color.ui default to 'auto'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-05-15T17:56:44Z","receivedAt":"2013-05-15T17:56:44Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> I think you are missing the entire point, which is not \"is anyone\n> harmed?\"\n\nAgain, it is. If the new default is really harmful for too many people,\nthen documentations will have to mention how to fix it.\n\nAnd really, I do not forsee any newbie-oriented starting with \"here's\nhow to disable colors in case you need it\", because of the reasons\nmentionned in the message.\n\n> Our recommendation has been \"use color=auto\"\n\nNot really. Neither Documentation/gittutorial.txt nor\nDocumentation/user-manual.txt mention colors. Pro Git mentions it, but\nmore as a possibility than as a recommandation. This is the\nrecommandation of the rest of the world, not \"ours\".\n\nIt's not \"either we update the docs or we update the code\", it's \"follow\nwhat the rest of the world is doing\", and \"rest of the world\" has to\nimply a notion of majority (not all tutorials talk about color.ui).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"217463","messageId":"7vppwsazg7.fsf@alter.siamese.dyndns.org","threadId":"33822","inReplyTo":"vpqwqr0azz7.fsf@grenoble-inp.fr","subject":"Re: [PATCH] make color.ui default to 'auto'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-15T18:08:08Z","receivedAt":"2013-05-15T18:08:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> I think you are missing the entire point, which is not \"is anyone\n>> harmed?\"\n>\n> Again, it is. If the new default is really harmful for too many people,\n> then documentations will have to mention how to fix it.\n>\n> And really, I do not forsee any newbie-oriented starting with \"here's\n> how to disable colors in case you need it\", because of the reasons\n> mentionned in the message.\n>\n>> Our recommendation has been \"use color=auto\"\n>\n> Not really. Neither Documentation/gittutorial.txt nor\n> Documentation/user-manual.txt mention colors. Pro Git mentions it, but\n> more as a possibility than as a recommandation. This is the\n> recommandation of the rest of the world, not \"ours\".\n\nDo you mean the git users who learn and use Git without being in the\ncircle of people who updates Documentation/ hierarchy \"the rest of\nthe world\"?\n\nI think that is a flawed mentality. They are part of \"us\".\n\n> It's not \"either we update the docs or we update the code\", it's \"follow\n> what the rest of the world is doing\", and \"rest of the world\" has to\n> imply a notion of majority (not all tutorials talk about color.ui).\n\nYes, exactly.\n\nRead the statement you made again, with the assumption that\neverybody (\"the rest of the world\") already knows (and/or agreed to)\ncolouring is a good thing.\n\n> ... Other beginners do not know about\n> color.ui=auto, and may not discover it by themselves, hence live with\n> black&white outputs while they may have prefered colors.\n>\n> A few people (e.g. color-blind) prefer having no colors, but they can\n> easily set color.ui=never for this (and googling \"disable colors in git\"\n> already tells them how to do so).\n\nNow, realize that after switching the default, these \"few people\"\nhave to live with distracting (or unreadable) output. Because these\npeople are minority, their websearch \"disable colors in git\" will by\ndefinition have smaller number of hits than \"enable colors in git\"\nthe above claims people \"may not discover it by themselves\". In a\nway, you are making things even harder because these minority do not\nhave many similar others to ask help for.\n\nThat is the honest way to express what you said in the second\nparagraph.\n\nIf we really want to justify the changing of the default, we should\nnot try to weasel out by using asymmetric wording from the fact that\nwe are making things less convenient for one kind of people. We\nshould be honest and say what we are doing: \"it will make things\neasier for majority while making it less convenient for minority\".\n\nI am however saying that in this case, we are better off not even\ntrying to come up with such a lame excuse for us to hurt color-blind\npeople in order to make things easier for majority. Just saying\n\"the rest of the world prefer automatic color and that is what we\nrecommend, so make the code match\" should be sufficient.\n"},{"id":"217466","messageId":"vpqli7gayts.fsf@grenoble-inp.fr","threadId":"33822","inReplyTo":"7vppwsazg7.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] make color.ui default to 'auto'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-05-15T18:21:35Z","receivedAt":"2013-05-15T18:21:35Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Now, realize that after switching the default, these \"few people\"\n> have to live with distracting (or unreadable) output. Because these\n> people are minority, their websearch \"disable colors in git\" will by\n> definition have smaller number of hits than \"enable colors in git\"\n> the above claims people \"may not discover it by themselves\".\n\nAs my message says, \"disable colors in git\" already gives you the\nanswer, today (1st hit in Google). I'm not worried about the difficulty\nto find the information in the future.\n\n> We should be honest and say what we are doing: \"it will make things\n> easier for majority while making it less convenient for minority\".\n\nI thought this was what I did, but your first complain was I was\nmentionning the majority, and you are now suggesting something about\nmajority/minority, so I'm lost.\n\nIn any case, feel free to change the commit message, what's really\nimportant is the actual change, and it does not seem controversial.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"217468","messageId":"7vhai4ayby.fsf@alter.siamese.dyndns.org","threadId":"33822","inReplyTo":"vpqli7gayts.fsf@grenoble-inp.fr","subject":"Re: [PATCH] make color.ui default to 'auto'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-15T18:32:17Z","receivedAt":"2013-05-15T18:32:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n>> We should be honest and say what we are doing: \"it will make things\n>> easier for majority while making it less convenient for minority\".\n>\n> I thought this was what I did, but your first complain was I was\n> mentionning the majority, and you are now suggesting something about\n> majority/minority, so I'm lost.\n\nNot really. My main complaint is that you were making it sound as\nif the inconvenience for the \"majority\" is very severe with \"many\nnot discover\", \"live with\", and such phrases, while making the\ninconveience you are placing on the \"minority\" trivial with \"easily\nset\" and \"already tells them\". That sounds a lot more like making a\nlame excuse than doing a balanced analysis of pros and cons of the\nchange.\n"},{"id":"217471","messageId":"CAMP44s3hk38iKzKw=r9MqNh_dyG5q7NVdO2iQc9jMurT+H8QcQ@mail.gmail.com","threadId":"33822","inReplyTo":"7vhai4ayby.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] make color.ui default to 'auto'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-15T19:41:03Z","receivedAt":"2013-05-15T19:41:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 15, 2013 at 1:32 PM, Junio C Hamano wrote:\n> Matthieu Moy writes:\n>\n>>> We should be honest and say what we are doing: \"it will make things\n>>> easier for majority while making it less convenient for minority\".\n>>\n>> I thought this was what I did, but your first complain was I was\n>> mentionning the majority, and you are now suggesting something about\n>> majority/minority, so I'm lost.\n>\n> Not really. My main complaint is that you were making it sound as\n> if the inconvenience for the \"majority\" is very severe with \"many\n> not discover\", \"live with\", and such phrases, while making the\n> inconveience you are placing on the \"minority\" trivial with \"easily\n> set\" and \"already tells them\". That sounds a lot more like making a\n> lame excuse than doing a balanced analysis of pros and cons of the\n> change.\n\nI could barely parse this, but I've found that many colleagues didn't\nknow about this configuration. And I don't see why anybody would not\nwant this. The minority that don't want this can search the interwebs\nto find out how to disable the unwanted behavior, so the majority that\ndo want this don't have to enable it all the time (*if* they know\nabout it).\n\n-- \nFelipe Contreras\n"}]}