{"thread":{"id":"35120","subject":"[PATCH v3] Add core.mode configuration","startedAt":"2013-10-12T07:04:45Z","lastAt":"2013-10-17T21:08:19Z","messageCount":25,"participants":["Felipe Contreras","Krzysztof Mazur","John Szakmeister","Philip Oakley","Jonathan Nieder"],"isPatch":true,"patchVersion":3,"patchTotal":null},"messages":[{"id":"228792","messageId":"1381561485-20252-1-git-send-email-felipe.contreras@gmail.com","threadId":"35120","inReplyTo":null,"subject":"[PATCH v3] Add core.mode configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-12T07:04:45Z","receivedAt":"2013-10-12T07:04:45Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"So that we can specify general modes of operation, specifically, add the\n'next' mode, which makes Git pre v2.0 behave as Git v2.0.\n\nSigned-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n builtin/add.c      | 13 ++++++++----\n cache.h            |  6 ++++++\n config.c           | 13 ++++++++++++\n environment.c      |  1 +\n t/t2205-add-new.sh | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 5 files changed, 89 insertions(+), 4 deletions(-)\n create mode 100755 t/t2205-add-new.sh\n\ndiff --git a/builtin/add.c b/builtin/add.c\nindex 8266a9c..95a396d 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -483,14 +483,16 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \t */\n \tmemset(&update_data, 0, sizeof(update_data));\n \tif (!take_worktree_changes && addremove_explicit < 0)\n-\t\tupdate_data.warn_add_would_remove = 1;\n+\t\tif (git_mode == MODE_CURRENT)\n+\t\t\tupdate_data.warn_add_would_remove = 1;\n \n \tif (!take_worktree_changes && addremove_explicit < 0 && argc)\n \t\t/*\n \t\t * Turn \"git add pathspec...\" to \"git add -A pathspec...\"\n \t\t * in Git 2.0 but not yet\n \t\t */\n-\t\t; /* addremove = 1; */\n+\t\tif (git_mode != MODE_CURRENT)\n+\t\t\taddremove = 1;\n \n \tif (!show_only && ignore_missing)\n \t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n@@ -503,10 +505,13 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \t\tshort_option_with_implicit_dot = \"-u\";\n \t}\n \tif (option_with_implicit_dot && !argc) {\n-\t\tstatic const char *here[2] = { \".\", NULL };\n+\t\tstatic const char *here[2] = { \":/\", NULL };\n \t\targc = 1;\n \t\targv = here;\n-\t\timplicit_dot = 1;\n+\t\tif (git_mode == MODE_CURRENT) {\n+\t\t\there[0] = \".\";\n+\t\t\timplicit_dot = 1;\n+\t\t}\n \t}\n \n \tadd_new_files = !take_worktree_changes && !refresh_only;\ndiff --git a/cache.h b/cache.h\nindex 85b544f..f28240f 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -627,9 +627,15 @@ enum push_default_type {\n \tPUSH_DEFAULT_UNSPECIFIED\n };\n \n+enum git_mode {\n+\tMODE_CURRENT = 0,\n+\tMODE_NEXT\n+};\n+\n extern enum branch_track git_branch_track;\n extern enum rebase_setup_type autorebase;\n extern enum push_default_type push_default;\n+extern enum git_mode git_mode;\n \n enum object_creation_mode {\n \tOBJECT_CREATION_USES_HARDLINKS = 0,\ndiff --git a/config.c b/config.c\nindex e13a7b6..f0e0370 100644\n--- a/config.c\n+++ b/config.c\n@@ -831,6 +831,19 @@ static int git_default_core_config(const char *var, const char *value)\n \t\treturn 0;\n \t}\n \n+\tif (!strcmp(var, \"core.mode\")) {\n+\t\tif (!value)\n+\t\t\treturn config_error_nonbool(var);\n+\t\telse if (!strcmp(value, \"current\"))\n+\t\t\tgit_mode = MODE_CURRENT;\n+\t\telse if (!strcmp(value, \"next\")) {\n+\t\t\tgit_mode = MODE_NEXT;\n+\t\t\tpush_default = PUSH_DEFAULT_SIMPLE;\n+\t\t} else\n+\t\t\tdie(\"wrong mode '%s'\", value);\n+\t\treturn 0;\n+\t}\n+\n \t/* Add other config variables here and to Documentation/config.txt. */\n \treturn 0;\n }\ndiff --git a/environment.c b/environment.c\nindex 5398c36..751e14d 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -62,6 +62,7 @@ int merge_log_config = -1;\n int precomposed_unicode = -1; /* see probe_utf8_pathname_composition() */\n struct startup_info *startup_info;\n unsigned long pack_size_limit_cfg;\n+enum git_mode git_mode = MODE_CURRENT;\n \n /*\n  * The character that begins a commented line in user-editable file\ndiff --git a/t/t2205-add-new.sh b/t/t2205-add-new.sh\nnew file mode 100755\nindex 0000000..763664b\n--- /dev/null\n+++ b/t/t2205-add-new.sh\n@@ -0,0 +1,60 @@\n+#!/bin/sh\n+\n+test_description='git add v2.0 behavior'\n+\n+. ./test-lib.sh\n+\n+test_expect_success setup '\n+\tmkdir dir1 &&\n+\techo one > dir1/content &&\n+\techo one > dir1/to-remove &&\n+\tgit add . &&\n+\tgit commit -m one\n+'\n+\n+test_expect_success 'update in dir throws warning' '\n+\ttest_when_finished \"git reset --hard\" &&\n+\techo two > dir1/content &&\n+\tmkdir -p dir2 &&\n+\t(\n+\tcd dir2 &&\n+\tgit add -u 2> err &&\n+\tcat err &&\n+\tgrep \"will change in Git 2.0\" err\n+\t)\n+'\n+\n+test_expect_success 'update in dir updates everything' '\n+\ttest_when_finished \"git reset --hard\" &&\n+\ttest_config core.mode next &&\n+\techo two > dir1/content &&\n+\tmkdir -p dir2 &&\n+\t(\n+\tcd dir2 &&\n+\tgit add -u 2> err &&\n+\tcat err &&\n+\t! grep \"will change in Git 2.0\" err\n+\t) &&\n+\ttest \"$(git ls-files -m)\" = \"\"\n+'\n+\n+test_expect_success 'default to ignore removal' '\n+\ttest_when_finished \"git reset --hard\" &&\n+\trm dir1/to-remove &&\n+\tgit add dir1 2> err &&\n+\tcat err &&\n+\tgrep \"will change in Git 2.0\" err &&\n+\ttest \"$(git ls-files -c)\" != \"dir1/content\"\n+'\n+\n+test_expect_success 'default adds removals' '\n+\ttest_when_finished \"git reset --hard\" &&\n+\ttest_config core.mode next &&\n+\trm dir1/to-remove &&\n+\tgit add dir1 2> err &&\n+\tcat err &&\n+\t! grep \"will change in Git 2.0\" err &&\n+\ttest \"$(git ls-files -c)\" = \"dir1/content\"\n+'\n+\n+test_done\n-- \n1.8.4-fc\n"},{"id":"228946","messageId":"20131014205908.GA17089@shrek.podlesie.net","threadId":"35120","inReplyTo":"1381561485-20252-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Krzysztof Mazur","fromEmail":"krzysiek@podlesie.net","sentAt":"2013-10-14T20:59:08Z","receivedAt":"2013-10-14T20:59:08Z","isPatch":true,"sender":{"key":"krzysiek@podlesie.net","avatar":null},"body":"On Sat, Oct 12, 2013 at 02:04:45AM -0500, Felipe Contreras wrote:\n> So that we can specify general modes of operation, specifically, add the\n> 'next' mode, which makes Git pre v2.0 behave as Git v2.0.\n> \n> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n> ---\n\nI don't think that single option it's a good idea. From the user's\npoint of view I think that the way push.default was introduced and\nwill be changed is much better. So maybe it's better to just add\n\"core.addremove\" option instead?\n\nKrzysiek\n"},{"id":"228949","messageId":"525c63b6711fa_197a905e845b@nysa.notmuch","threadId":"35120","inReplyTo":"20131014205908.GA17089@shrek.podlesie.net","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-14T21:35:50Z","receivedAt":"2013-10-14T21:35:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Krzysztof Mazur wrote:\n> On Sat, Oct 12, 2013 at 02:04:45AM -0500, Felipe Contreras wrote:\n> > So that we can specify general modes of operation, specifically, add the\n> > 'next' mode, which makes Git pre v2.0 behave as Git v2.0.\n> > \n> > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n> > ---\n> \n> I don't think that single option it's a good idea. From the user's\n> point of view I think that the way push.default was introduced and\n> will be changed is much better. So maybe it's better to just add\n> \"core.addremove\" option instead?\n\nMaybe, but what happens when we start doing changes for v3.0? As a user, I\ndon't and to figure out which are the new configurations that will turn v3.0\nbehavior on, I just want to be testing that mode, even if I'm not following Git\ndevelopment closely. If I find something annoying with core.mode = next, I\nreport the problem to the mailing list, which is good, we want to know problems\nwith the backward-incompatible changes that will be introduced before it's too\nlate, don't we?\n\nI'd be fine with having *both* a fine-tuned option to trigger each specific\nbehavior, and another one that turns all those fine-tuned options on that are\nmeant for v2.0.\n\nUnfortunately, I don't see much interest from Git developers in either.\n\n-- \nFelipe Contreras\n"},{"id":"229006","messageId":"525d35e766ad4_55661275e7426@nysa.notmuch","threadId":"35120","inReplyTo":"20131015123505.GA3097@shrek.podlesie.net","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-15T12:32:39Z","receivedAt":"2013-10-15T12:32:39Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Krzysztof Mazur wrote:\n> On Mon, Oct 14, 2013 at 04:35:50PM -0500, Felipe Contreras wrote:\n> > Krzysztof Mazur wrote:\n> > > On Sat, Oct 12, 2013 at 02:04:45AM -0500, Felipe Contreras wrote:\n> > > > So that we can specify general modes of operation, specifically, add the\n> > > > 'next' mode, which makes Git pre v2.0 behave as Git v2.0.\n> > > > \n> > > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n> > > > ---\n> > > \n> > > I don't think that single option it's a good idea. From the user's\n> > > point of view I think that the way push.default was introduced and\n> > > will be changed is much better. So maybe it's better to just add\n> > > \"core.addremove\" option instead?\n> > \n> > Maybe, but what happens when we start doing changes for v3.0? As a user, I\n> > don't and to figure out which are the new configurations that will turn v3.0\n> > behavior on, I just want to be testing that mode, even if I'm not following Git\n> > development closely. If I find something annoying with core.mode = next, I\n> > report the problem to the mailing list, which is good, we want to know problems\n> > with the backward-incompatible changes that will be introduced before it's too\n> > late, don't we?\n> \n> But with core.mode = next after upgrade you may experience incompatible\n> change without any warning.\n\nYes, and that is actually what the user wants. I mean, why would the user set\ncore.mode=next, if the user doesn't want to experencie incompatible changes? A\nuser that sets this mode is expecting incompatible changes, and will be willing\nto test them, and report back if there's any problem with them.\n\n> I think it's better to keep the old behavior by default and warn the user if\n> with new behavior the result might be different. So the user:\n> \n> \ta) knows about the change\n> \n> \tb) may set appropriate option to enable the new default or keep\n> \t   the old behavior and disable the warning\n> \n> \tc) may report that he does not like that change\n\nBut that's what we are doing already. Look at the test I wrote, it's testing\nthe warnings for the current version of Git.\n\n> > I'd be fine with having *both* a fine-tuned option to trigger each specific\n> > behavior, and another one that turns all those fine-tuned options on that are\n> > meant for v2.0.\n> > \n> > Unfortunately, I don't see much interest from Git developers in either.\n> \n> I think that most users have already set the push.default, so \"git add\"\n> is the only problem. If Junio really wants to change \"git add\" he should\n> be interested in allowing user to use it now.\n\nI agree, but he really wants the change, and proof of that is that the warning\nis already there, and every Git release since then has an annoying message\nabout that at the top.\n\n> I don't see the change in \"git add\" as an improvement, because\n> removing files with \"git add\" IMHO is more confusing than ignoring\n> such files. Maybe introducing new command - \"git update\" for instance -\n> which is equivalent to new \"git add\" and teaching new users to use it\n> instead of \"git add\" is better.\n\nI agree. At first I simply ignored the changes because I didn't have the\npatience to figure out what exactly did they mean. Now I was forced to\nunderstand them to write this patch, and I'm also forcing myself to use this\nbehavior.\n\n'git add' removing files is counter-intutive, 'git stage' (currently an alias\nto 'git add') might make more sense.\n\nBut even better would be to use my proposed changes to 'git stage', which add\nsubcommands, for example:\n\n * git stage all (git add --all)\n * git stage update (git add --update)\n\nBut it doesn't seem that patch is going to be applied by Junio, so most likely\nwe would have to deal with yet anotyer counter-intuitive behavior in Git.\n\n-- \nFelipe Contreras\n"},{"id":"229005","messageId":"20131015123505.GA3097@shrek.podlesie.net","threadId":"35120","inReplyTo":"525c63b6711fa_197a905e845b@nysa.notmuch","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Krzysztof Mazur","fromEmail":"krzysiek@podlesie.net","sentAt":"2013-10-15T12:35:05Z","receivedAt":"2013-10-15T12:35:05Z","isPatch":true,"sender":{"key":"krzysiek@podlesie.net","avatar":null},"body":"On Mon, Oct 14, 2013 at 04:35:50PM -0500, Felipe Contreras wrote:\n> Krzysztof Mazur wrote:\n> > On Sat, Oct 12, 2013 at 02:04:45AM -0500, Felipe Contreras wrote:\n> > > So that we can specify general modes of operation, specifically, add the\n> > > 'next' mode, which makes Git pre v2.0 behave as Git v2.0.\n> > > \n> > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n> > > ---\n> > \n> > I don't think that single option it's a good idea. From the user's\n> > point of view I think that the way push.default was introduced and\n> > will be changed is much better. So maybe it's better to just add\n> > \"core.addremove\" option instead?\n> \n> Maybe, but what happens when we start doing changes for v3.0? As a user, I\n> don't and to figure out which are the new configurations that will turn v3.0\n> behavior on, I just want to be testing that mode, even if I'm not following Git\n> development closely. If I find something annoying with core.mode = next, I\n> report the problem to the mailing list, which is good, we want to know problems\n> with the backward-incompatible changes that will be introduced before it's too\n> late, don't we?\n\nBut with core.mode = next after upgrade you may experience incompatible\nchange without any warning. I think it's better to keep the old behavior\nby default and warn the user if with new behavior the result might be\ndifferent. So the user:\n\n\ta) knows about the change\n\n\tb) may set appropriate option to enable the new default or keep\n\t   the old behavior and disable the warning\n\n\tc) may report that he does not like that change\n\n> \n> I'd be fine with having *both* a fine-tuned option to trigger each specific\n> behavior, and another one that turns all those fine-tuned options on that are\n> meant for v2.0.\n> \n> Unfortunately, I don't see much interest from Git developers in either.\n> \n\nI think that most users have already set the push.default, so \"git add\"\nis the only problem. If Junio really wants to change \"git add\" he should\nbe interested in allowing user to use it now.\n\nI don't see the change in \"git add\" as an improvement, because\nremoving files with \"git add\" IMHO is more confusing than ignoring\nsuch files. Maybe introducing new command - \"git update\" for instance -\nwhich is equivalent to new \"git add\" and teaching new users to use it\ninstead of \"git add\" is better.\n\nKrzysiek\n"},{"id":"229009","messageId":"525d4354a5436_5844e73e843d@nysa.notmuch","threadId":"35120","inReplyTo":"20131015133327.GA22723@shrek.podlesie.net","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-15T13:29:56Z","receivedAt":"2013-10-15T13:29:56Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Krzysztof Mazur wrote:\n> On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:\n> > Krzysztof Mazur wrote:\n> > > \n> > > But with core.mode = next after upgrade you may experience incompatible\n> > > change without any warning.\n> > \n> > Yes, and that is actually what the user wants. I mean, why would the user set\n> > core.mode=next, if the user doesn't want to experencie incompatible changes? A\n> > user that sets this mode is expecting incompatible changes, and will be willing\n> > to test them, and report back if there's any problem with them.\n> \n> With your patch, because it's the only way to have 'git add' v2.0.\n\nYeah, but that's not what I'm suggesting. I suggested to have *both* a\nfined-tunned way to have this behavior, say core.addremove = true, and a way to\nenable *all* v2.0 behaviors (core.mode = next).\n\nIf we have both, and the user sets core.mode = next, that means the user wants\n*all* the incompatible changes.\n\n> But if another git v2.0 incompatible change will be added it will not\n> be warned, because with core.mode=next he decided to enable also\n> future changes and that's why I would never set that.\n\nThat's fine, you wouldn't set that, but I would. That's why it's a\nconfiguration.\n\n> > > I think it's better to keep the old behavior by default and warn the user if\n> > > with new behavior the result might be different. So the user:\n> > > \n> > > \ta) knows about the change\n> > > \n> > > \tb) may set appropriate option to enable the new default or keep\n> > > \t   the old behavior and disable the warning\n> > > \n> > > \tc) may report that he does not like that change\n> > \n> > But that's what we are doing already. Look at the test I wrote, it's testing\n> > the warnings for the current version of Git.\n> \n> With pull.default we did that, but with git add v2.0 now we only warn\n> the user. With your patch he can enable new git add (and disable warning),\n> but he also enables future incompatible changes and disables\n> warnings for such changes.\n\nYeah, but I suggested to have *both* a fine-tunned option and a general one,\ndidn't I?\n\n> He also cannot keep the old behaviour and disable the warning.\n\nHe cannot do that regardless if my patch is merged or not.\n\n> > > I don't see the change in \"git add\" as an improvement, because\n> > > removing files with \"git add\" IMHO is more confusing than ignoring\n> > > such files. Maybe introducing new command - \"git update\" for instance -\n> > > which is equivalent to new \"git add\" and teaching new users to use it\n> > > instead of \"git add\" is better.\n> > \n> > I agree. At first I simply ignored the changes because I didn't have the\n> > patience to figure out what exactly did they mean. Now I was forced to\n> > understand them to write this patch, and I'm also forcing myself to use this\n> > behavior.\n> > \n> > 'git add' removing files is counter-intutive, 'git stage' (currently an alias\n> > to 'git add') might make more sense.\n> \n> Yeah, 'git stage' as an alias to 'git add -A' is much more intuitive.\n\nAgreed.\n\n-- \nFelipe Contreras\n"},{"id":"229007","messageId":"20131015133327.GA22723@shrek.podlesie.net","threadId":"35120","inReplyTo":"525d35e766ad4_55661275e7426@nysa.notmuch","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Krzysztof Mazur","fromEmail":"krzysiek@podlesie.net","sentAt":"2013-10-15T13:33:27Z","receivedAt":"2013-10-15T13:33:27Z","isPatch":true,"sender":{"key":"krzysiek@podlesie.net","avatar":null},"body":"On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:\n> Krzysztof Mazur wrote:\n> > \n> > But with core.mode = next after upgrade you may experience incompatible\n> > change without any warning.\n> \n> Yes, and that is actually what the user wants. I mean, why would the user set\n> core.mode=next, if the user doesn't want to experencie incompatible changes? A\n> user that sets this mode is expecting incompatible changes, and will be willing\n> to test them, and report back if there's any problem with them.\n\nWith your patch, because it's the only way to have 'git add' v2.0.\nBut if another git v2.0 incompatible change will be added it will not\nbe warned, because with core.mode=next he decided to enable also\nfuture changes and that's why I would never set that.\n\n> \n> > I think it's better to keep the old behavior by default and warn the user if\n> > with new behavior the result might be different. So the user:\n> > \n> > \ta) knows about the change\n> > \n> > \tb) may set appropriate option to enable the new default or keep\n> > \t   the old behavior and disable the warning\n> > \n> > \tc) may report that he does not like that change\n> \n> But that's what we are doing already. Look at the test I wrote, it's testing\n> the warnings for the current version of Git.\n\nWith pull.default we did that, but with git add v2.0 now we only warn\nthe user. With your patch he can enable new git add (and disable warning),\nbut he also enables future incompatible changes and disables\nwarnings for such changes. He also cannot keep the old behaviour and\ndisable the warning.\n\n> \n> > I don't see the change in \"git add\" as an improvement, because\n> > removing files with \"git add\" IMHO is more confusing than ignoring\n> > such files. Maybe introducing new command - \"git update\" for instance -\n> > which is equivalent to new \"git add\" and teaching new users to use it\n> > instead of \"git add\" is better.\n> \n> I agree. At first I simply ignored the changes because I didn't have the\n> patience to figure out what exactly did they mean. Now I was forced to\n> understand them to write this patch, and I'm also forcing myself to use this\n> behavior.\n> \n> 'git add' removing files is counter-intutive, 'git stage' (currently an alias\n> to 'git add') might make more sense.\n\nYeah, 'git stage' as an alias to 'git add -A' is much more intuitive.\n\nKrzysiek\n"},{"id":"229012","messageId":"20131015145139.GA3977@shrek.podlesie.net","threadId":"35120","inReplyTo":"525d4354a5436_5844e73e843d@nysa.notmuch","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Krzysztof Mazur","fromEmail":"krzysiek@podlesie.net","sentAt":"2013-10-15T14:51:40Z","receivedAt":"2013-10-15T14:51:40Z","isPatch":true,"sender":{"key":"krzysiek@podlesie.net","avatar":null},"body":"On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote:\n> Krzysztof Mazur wrote:\n> > On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:\n> > > Krzysztof Mazur wrote:\n> > > > \n> > > > But with core.mode = next after upgrade you may experience incompatible\n> > > > change without any warning.\n> > > \n> > > Yes, and that is actually what the user wants. I mean, why would the user set\n> > > core.mode=next, if the user doesn't want to experencie incompatible changes? A\n> > > user that sets this mode is expecting incompatible changes, and will be willing\n> > > to test them, and report back if there's any problem with them.\n> > \n> > With your patch, because it's the only way to have 'git add' v2.0.\n> \n> Yeah, but that's not what I'm suggesting. I suggested to have *both* a\n> fined-tunned way to have this behavior, say core.addremove = true, and a way to\n> enable *all* v2.0 behaviors (core.mode = next).\n\nI'm just not sure if a lot of users would use core.mode=next, because\nof possible different behavior without any warning. Maybe we should also\nadd core.mode=next-warn that changes defaults like next but keeps warnings\nenabled until the user accepts that change by setting appropriate\nconfig option? That's safer than next (at least for interactive use) and\nmaybe more users would use that, but I don't think that's worth adding.\n\nFor me, old behavior by default and warnings with information how to\nenable new incompatible features, is sufficient. So I don't need\ncore.mode option, but as long it will be useful for other users I have\nnothing against it.\n\nKrzysiek\n"},{"id":"229013","messageId":"CAEBDL5V8wfbQTZ5do-UMRpSsxRN8bFaHVnG7kRNfP0t+oYbfNg@mail.gmail.com","threadId":"35120","inReplyTo":"20131015145139.GA3977@shrek.podlesie.net","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-10-15T16:59:48Z","receivedAt":"2013-10-15T16:59:48Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Tue, Oct 15, 2013 at 10:51 AM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:\n> On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote:\n>> Krzysztof Mazur wrote:\n>> > On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:\n>> > > Krzysztof Mazur wrote:\n>> > > >\n>> > > > But with core.mode = next after upgrade you may experience incompatible\n>> > > > change without any warning.\n>> > >\n>> > > Yes, and that is actually what the user wants. I mean, why would the user set\n>> > > core.mode=next, if the user doesn't want to experencie incompatible changes? A\n>> > > user that sets this mode is expecting incompatible changes, and will be willing\n>> > > to test them, and report back if there's any problem with them.\n>> >\n>> > With your patch, because it's the only way to have 'git add' v2.0.\n>>\n>> Yeah, but that's not what I'm suggesting. I suggested to have *both* a\n>> fined-tunned way to have this behavior, say core.addremove = true, and a way to\n>> enable *all* v2.0 behaviors (core.mode = next).\n>\n> I'm just not sure if a lot of users would use core.mode=next, because\n> of possible different behavior without any warning. Maybe we should also\n> add core.mode=next-warn that changes defaults like next but keeps warnings\n> enabled until the user accepts that change by setting appropriate\n> config option? That's safer than next (at least for interactive use) and\n> maybe more users would use that, but I don't think that's worth adding.\n\nI like the idea that we could kick git into a mode that applies the\nbehaviors we're talking about having in 2.0, but I'm concerned about\none aspect of it.  Not having these behaviors until 2.0 hits means\nwe're free to renege on our decisions in favor of something better, or\nto pull out a bad idea.  But once we insert this knob, I don't know\nthat we have the same ability.  Once people realize it's there and\nstart using it, it gets harder to back out.  I guess we could maintain\nthe stance that \"the features are not concrete yet,\" or something like\nthat, but I think people would still get upset if something changes\nout from under them.\n\nSo, at the end of the day, I'm just not sure it's worthwhile to have.\n\n-John\n"},{"id":"229019","messageId":"525d8ebd19c67_5feab61e8037@nysa.notmuch","threadId":"35120","inReplyTo":"20131015145139.GA3977@shrek.podlesie.net","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-15T18:51:41Z","receivedAt":"2013-10-15T18:51:41Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Krzysztof Mazur wrote:\n> On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote:\n> > Krzysztof Mazur wrote:\n> > > On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:\n> > > > Krzysztof Mazur wrote:\n> > > > > \n> > > > > But with core.mode = next after upgrade you may experience incompatible\n> > > > > change without any warning.\n> > > > \n> > > > Yes, and that is actually what the user wants. I mean, why would the user set\n> > > > core.mode=next, if the user doesn't want to experencie incompatible changes? A\n> > > > user that sets this mode is expecting incompatible changes, and will be willing\n> > > > to test them, and report back if there's any problem with them.\n> > > \n> > > With your patch, because it's the only way to have 'git add' v2.0.\n> > \n> > Yeah, but that's not what I'm suggesting. I suggested to have *both* a\n> > fined-tunned way to have this behavior, say core.addremove = true, and a way to\n> > enable *all* v2.0 behaviors (core.mode = next).\n> \n> I'm just not sure if a lot of users would use core.mode=next,\n\nI'm not sure if a lot of urser would even notice the difference.\n\n> because of possible different behavior without any warning.\n\nI don't see what is the problem. We haven't had the need for push.default =\nsimplewarning, have we? If you want the warning, you don't change anything, if\nyou want to specify something, you already know what you are doing.\n\n> Maybe we should also add core.mode=next-warn that changes defaults like next\n> but keeps warnings enabled until the user accepts that change by setting\n> appropriate config option?\n\nMaybe, but would you actually use that option?\n\n> That's safer than next (at least for interactive use) and maybe more users\n> would use that, but I don't think that's worth adding.\n\nMaybe, but I don't think many users would use either mode, and that's good.\n\n> For me, old behavior by default and warnings with information how to\n> enable new incompatible features, is sufficient. So I don't need\n> core.mode option, but as long it will be useful for other users I have\n> nothing against it.\n\nOK, but that seems to mean you don't need core.mode = next-warn either. I'm not\nagainst adding such a mode, but I would like to hear about _somebody_ that\nwould like to actually use it. I don't like to program for ghosts.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"229028","messageId":"20131015220125.GA14021@shrek.podlesie.net","threadId":"35120","inReplyTo":"525d8ebd19c67_5feab61e8037@nysa.notmuch","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Krzysztof Mazur","fromEmail":"krzysiek@podlesie.net","sentAt":"2013-10-15T22:01:25Z","receivedAt":"2013-10-15T22:01:25Z","isPatch":true,"sender":{"key":"krzysiek@podlesie.net","avatar":null},"body":"On Tue, Oct 15, 2013 at 01:51:41PM -0500, Felipe Contreras wrote:\n> \n> I don't see what is the problem. We haven't had the need for push.default =\n> simplewarning, have we? If you want the warning, you don't change anything, if\n\nsimplewarning makes no sense, because push.default=simple sets exact\nbehavior, not some \"next\" behavior that may change in future.\n\nFor instance, I was very unhappy once, when git pull failed and said\nthat I should do git pull --merge.\n\n> you want to specify something, you already know what you are doing.\n> \n> > Maybe we should also add core.mode=next-warn that changes defaults like next\n> > but keeps warnings enabled until the user accepts that change by setting\n> > appropriate config option?\n> \n> Maybe, but would you actually use that option?\n\nNo.\n\n> \n> > That's safer than next (at least for interactive use) and maybe more users\n> > would use that, but I don't think that's worth adding.\n> \n> Maybe, but I don't think many users would use either mode, and that's good.\n> \n> > For me, old behavior by default and warnings with information how to\n> > enable new incompatible features, is sufficient. So I don't need\n> > core.mode option, but as long it will be useful for other users I have\n> > nothing against it.\n> \n> OK, but that seems to mean you don't need core.mode = next-warn either. I'm not\n> against adding such a mode, but I would like to hear about _somebody_ that\n> would like to actually use it. I don't like to program for ghosts.\n>\n\nAs I said earlier, I don't think that next-warn it's worth adding, but\nsuch option might increase the number of people interested in the\ncore.mode.\n\nKrzysiek\n"},{"id":"229056","messageId":"525e0e1b28c87_81a151de743f@nysa.notmuch","threadId":"35120","inReplyTo":"CAEBDL5V8wfbQTZ5do-UMRpSsxRN8bFaHVnG7kRNfP0t+oYbfNg@mail.gmail.com","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-16T03:55:07Z","receivedAt":"2013-10-16T03:55:07Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"John Szakmeister wrote:\n> On Tue, Oct 15, 2013 at 10:51 AM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:\n> > On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote:\n> >> Krzysztof Mazur wrote:\n> >> > On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:\n> >> > > Krzysztof Mazur wrote:\n> >> > > >\n> >> > > > But with core.mode = next after upgrade you may experience incompatible\n> >> > > > change without any warning.\n> >> > >\n> >> > > Yes, and that is actually what the user wants. I mean, why would the user set\n> >> > > core.mode=next, if the user doesn't want to experencie incompatible changes? A\n> >> > > user that sets this mode is expecting incompatible changes, and will be willing\n> >> > > to test them, and report back if there's any problem with them.\n> >> >\n> >> > With your patch, because it's the only way to have 'git add' v2.0.\n> >>\n> >> Yeah, but that's not what I'm suggesting. I suggested to have *both* a\n> >> fined-tunned way to have this behavior, say core.addremove = true, and a way to\n> >> enable *all* v2.0 behaviors (core.mode = next).\n> >\n> > I'm just not sure if a lot of users would use core.mode=next, because\n> > of possible different behavior without any warning. Maybe we should also\n> > add core.mode=next-warn that changes defaults like next but keeps warnings\n> > enabled until the user accepts that change by setting appropriate\n> > config option? That's safer than next (at least for interactive use) and\n> > maybe more users would use that, but I don't think that's worth adding.\n> \n> I like the idea that we could kick git into a mode that applies the\n> behaviors we're talking about having in 2.0, but I'm concerned about\n> one aspect of it.  Not having these behaviors until 2.0 hits means\n> we're free to renege on our decisions in favor of something better, or\n> to pull out a bad idea.  But once we insert this knob, I don't know\n> that we have the same ability.  Once people realize it's there and\n> start using it, it gets harder to back out.  I guess we could maintain\n> the stance that \"the features are not concrete yet,\" or something like\n> that, but I think people would still get upset if something changes\n> out from under them.\n\nWe cannot change the behavior of push.default = simple already, so at least\nthat option is not in question.\n\nPresumably you are worried about the other options that can't be enabled in any\nway.\n\nBut think about this; you are worried that if we add an *option* to enable this\nnew behaviors, then we would be kind of forced to keep these behaviors. That\nseems to imply that you are proposing the current default; we wait until 2.0\nand not make it an *option*, but make it *default*.\n\nI think waiting until 2.0 to make it a default without evern having an option,\nand thus nobody actuallly testing this, is way worst than what I'm proposing;\nto add an option to start testing.\n\n> So, at the end of the day, I'm just not sure it's worthwhile to have.\n\nThis is exactly what happened on 1.6; nobody really tested the 'git foo'\nbehavior, so we just switched from one version to the next. If you are not\nfamiliar with the outcome; it wasn't good.\n\nSo I say we shouldn't just provide warnings, but also have an option to allow\nusers (probably a minority) to start testing this.\n\n-- \nFelipe Contreras\n"},{"id":"229057","messageId":"525e100e45ee8_81a151de74ed@nysa.notmuch","threadId":"35120","inReplyTo":"20131015220125.GA14021@shrek.podlesie.net","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-16T04:03:26Z","receivedAt":"2013-10-16T04:03:26Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Krzysztof Mazur wrote:\n> On Tue, Oct 15, 2013 at 01:51:41PM -0500, Felipe Contreras wrote:\n> > \n> > I don't see what is the problem. We haven't had the need for push.default =\n> > simplewarning, have we? If you want the warning, you don't change anything, if\n> \n> simplewarning makes no sense, because push.default=simple sets exact\n> behavior,\n\nExactly.\n\n> not some \"next\" behavior that may change in future.\n\nBut I'm suggesting to add a core.addremove option as well, like you suggested,\nam I not?\n\nThat option wouldn't change in the future.\n\n> > you want to specify something, you already know what you are doing.\n> > \n> > > Maybe we should also add core.mode=next-warn that changes defaults like next\n> > > but keeps warnings enabled until the user accepts that change by setting\n> > > appropriate config option?\n> > \n> > Maybe, but would you actually use that option?\n> \n> No.\n\nSo you would be happy if we had core.addremove = true *and* core.mode = next,\nright? You would use one, different people with different needs would use the\nother.\n\n> > > That's safer than next (at least for interactive use) and maybe more users\n> > > would use that, but I don't think that's worth adding.\n> > \n> > Maybe, but I don't think many users would use either mode, and that's good.\n> > \n> > > For me, old behavior by default and warnings with information how to\n> > > enable new incompatible features, is sufficient. So I don't need\n> > > core.mode option, but as long it will be useful for other users I have\n> > > nothing against it.\n> > \n> > OK, but that seems to mean you don't need core.mode = next-warn either. I'm not\n> > against adding such a mode, but I would like to hear about _somebody_ that\n> > would like to actually use it. I don't like to program for ghosts.\n> >\n> \n> As I said earlier, I don't think that next-warn it's worth adding, but\n> such option might increase the number of people interested in the\n> core.mode.\n\nWell that's a hypothesis, and I would be interested in finding out if that's\ntrue, but until I see somebody that says \"I want core.mode = next-war\", I'm\ngoing to assume they are hypothetical.\n\n-- \nFelipe Contreras\n"},{"id":"229058","messageId":"20131016063436.GB24964@shrek.podlesie.net","threadId":"35120","inReplyTo":"525e100e45ee8_81a151de74ed@nysa.notmuch","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Krzysztof Mazur","fromEmail":"krzysiek@podlesie.net","sentAt":"2013-10-16T06:34:36Z","receivedAt":"2013-10-16T06:34:36Z","isPatch":true,"sender":{"key":"krzysiek@podlesie.net","avatar":null},"body":"On Tue, Oct 15, 2013 at 11:03:26PM -0500, Felipe Contreras wrote:\n> > not some \"next\" behavior that may change in future.\n> \n> But I'm suggesting to add a core.addremove option as well, like you suggested,\n> am I not?\n\nYes, I think we both agreed on adding core.addremove. I'm just not\nconvinced if we should also add core.mode.\n\n> \n> So you would be happy if we had core.addremove = true *and* core.mode = next,\n> right? You would use one, different people with different needs would use the\n> other.\n\nYes, if there are people that will use core.mode it will be worth\nadding. I'm just not one of them.\n\n> \n> > > > That's safer than next (at least for interactive use) and maybe more users\n> > > > would use that, but I don't think that's worth adding.\n> > > \n> > > Maybe, but I don't think many users would use either mode, and that's good.\n> > > \n> > > > For me, old behavior by default and warnings with information how to\n> > > > enable new incompatible features, is sufficient. So I don't need\n> > > > core.mode option, but as long it will be useful for other users I have\n> > > > nothing against it.\n> > > \n> > > OK, but that seems to mean you don't need core.mode = next-warn either. I'm not\n> > > against adding such a mode, but I would like to hear about _somebody_ that\n> > > would like to actually use it. I don't like to program for ghosts.\n> > >\n> > \n> > As I said earlier, I don't think that next-warn it's worth adding, but\n> > such option might increase the number of people interested in the\n> > core.mode.\n> \n> Well that's a hypothesis, and I would be interested in finding out if that's\n> true, but until I see somebody that says \"I want core.mode = next-war\", I'm\n> going to assume they are hypothetical.\n> \n\nYes, that's just a hypothesis.\n\nKrzysiek\n"},{"id":"229061","messageId":"20131016070900.GC24964@shrek.podlesie.net","threadId":"35120","inReplyTo":"525e0e1b28c87_81a151de743f@nysa.notmuch","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Krzysztof Mazur","fromEmail":"krzysiek@podlesie.net","sentAt":"2013-10-16T07:09:00Z","receivedAt":"2013-10-16T07:09:00Z","isPatch":true,"sender":{"key":"krzysiek@podlesie.net","avatar":null},"body":"On Tue, Oct 15, 2013 at 10:55:07PM -0500, Felipe Contreras wrote:\n> John Szakmeister wrote:\n> > \n> > I like the idea that we could kick git into a mode that applies the\n> > behaviors we're talking about having in 2.0, but I'm concerned about\n> > one aspect of it.  Not having these behaviors until 2.0 hits means\n> > we're free to renege on our decisions in favor of something better, or\n> > to pull out a bad idea.  But once we insert this knob, I don't know\n> > that we have the same ability.  Once people realize it's there and\n> > start using it, it gets harder to back out.  I guess we could maintain\n> > the stance that \"the features are not concrete yet,\" or something like\n> > that, but I think people would still get upset if something changes\n> > out from under them.\n> \n> We cannot change the behavior of push.default = simple already, so at least\n> that option is not in question.\n\nIf we add core.addremove=true the same applies to it - we cannot remove\nit later, the only we can do is to disable it by default in future\nversions after testing (core.addremove=true or core.mode=next).\n\n> > So, at the end of the day, I'm just not sure it's worthwhile to have.\n> \n> This is exactly what happened on 1.6; nobody really tested the 'git foo'\n> behavior, so we just switched from one version to the next. If you are not\n> familiar with the outcome; it wasn't good.\n\nBTW, I'm still using pre-1.6 git-foo, I have /usr/libexec/git-core\nin my PATH. So I would like to always have an option to disable some\nnew incompatible \"improvements\".\n\n> \n> So I say we shouldn't just provide warnings, but also have an option to allow\n> users (probably a minority) to start testing this.\n> \n\nand an option to keep the old behavior, like we did with push.default.\n\nKrzysiek\n"},{"id":"229068","messageId":"CAEBDL5We2wshgMZcTXoDziXskKvb9s2=2DEZtXRBgbTiitCOZQ@mail.gmail.com","threadId":"35120","inReplyTo":"525e0e1b28c87_81a151de743f@nysa.notmuch","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-10-16T10:54:31Z","receivedAt":"2013-10-16T10:54:31Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n[snip]\n> We cannot change the behavior of push.default = simple already, so at least\n> that option is not in question.\n\nTrue.\n\n> Presumably you are worried about the other options that can't be enabled in any\n> way.\n\nYes.\n\n> But think about this; you are worried that if we add an *option* to enable this\n> new behaviors, then we would be kind of forced to keep these behaviors. That\n> seems to imply that you are proposing the current default; we wait until 2.0\n> and not make it an *option*, but make it *default*.\n>\n> I think waiting until 2.0 to make it a default without evern having an option,\n> and thus nobody actuallly testing this, is way worst than what I'm proposing;\n> to add an option to start testing.\n\nMy concern is that people don't treat it for what it is--a way to\nexperiment with the new behaviors--and then they get upset if we\ndiscover that some behavior was not well thought out and it disappears\n\"unexpectedly\" when we correct the matter.  We have a balance to\nstrike: annoying users and getting some miles on the new behaviors.  I\nsee the technical end of this--your proposal to have a\n'core.mode'--but where is the non-technical end of this argument?\nWhat message are we proposing to send to the users?  What's our\npromise to them surrounding core.mode and the new behaviors it offers?\n Perhaps we don't have much today that this affects, but what about\ntomorrow?  Are we saying that behaviors enabled by core.mode=next are\nconcrete (they're going in as-is, and we won't alter their behavior\nbefore 2.0)?\n\nAs I said, the only real drawback is that I see this as the latter,\nbecause any other choice means users will get annoyed when something\nchanges out from under them.\n\n>> So, at the end of the day, I'm just not sure it's worthwhile to have.\n>\n> This is exactly what happened on 1.6; nobody really tested the 'git foo'\n> behavior, so we just switched from one version to the next. If you are not\n> familiar with the outcome; it wasn't good.\n\nYou're right, I wasn't around for that.  And on the whole, I\nabsolutely agree: it's nice to get miles on these new\nbehaviors/features/etc.  I just worry that having an option like this\nmeans we've committed to it, and I'm not sure that we want to give up\nthe ability to change them without having to go through some sort of\ndeprecation cycle.  Or worse, we have to wait until 3.0 and 2.0 hasn't\neven come out yet.\n\nI hope others chime in here.  And don't mistake me as dissenting; I'm\nnot.  And, I'm not assenting either.  I just want to know if you've\nthought about what this means to users, and what we're prepared to\ndeal with.  Right now, I feel like half the argument around the option\nis missing.\n\n> So I say we shouldn't just provide warnings, but also have an option to allow\n> users (probably a minority) to start testing this.\n\n\"probably a minority\" -- I guess that's the part I disagree with.  I'm\nnot sure what a minority means here, but I don't think it'll be a\nhandful of people.  How big does that number get before we get\nconcerned about backlash from users if we decide to change course?\nOr, is that simply not an issue?  Why or why not?  I have to be\nhonest, if the option was available, I'd have my developers turn it\non.  I'm sure a great deal of others would do so too.\n\nIs there some other way we can solve this?  Having an experimental\nbranch with all the 2.0 features merged and those concerned can just\nbuild that version?  I see the downside of that too: it's not as easy\nfor people to try, and there is nothing preventing folks from posting\nbinaries with the new behaviors enabled.  It leads me to feeling that\nwe're stuck in some regard.  But maybe I'm being overly pessimistic\nhere, and it's really all a non-issue.  As I said earlier, it'd be\nnice if others chimed in here.\n\n-John\n"},{"id":"229072","messageId":"CAEBDL5UaowCZggHijoqPF2UP5B6Y6Bkr9eP+A-Z3-x71W1Oi6Q@mail.gmail.com","threadId":"35120","inReplyTo":"CAEBDL5We2wshgMZcTXoDziXskKvb9s2=2DEZtXRBgbTiitCOZQ@mail.gmail.com","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-10-16T15:11:44Z","receivedAt":"2013-10-16T15:11:44Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Wed, Oct 16, 2013 at 6:54 AM, John Szakmeister <john@szakmeister.net> wrote:\n[snip]\n> \"probably a minority\" -- I guess that's the part I disagree with.  I'm\n> not sure what a minority means here, but I don't think it'll be a\n> handful of people.  How big does that number get before we get\n> concerned about backlash from users if we decide to change course?\n> Or, is that simply not an issue?  Why or why not?  I have to be\n> honest, if the option was available, I'd have my developers turn it\n> on.  I'm sure a great deal of others would do so too.\n>\n> Is there some other way we can solve this?  Having an experimental\n> branch with all the 2.0 features merged and those concerned can just\n> build that version?  I see the downside of that too: it's not as easy\n> for people to try, and there is nothing preventing folks from posting\n> binaries with the new behaviors enabled.  It leads me to feeling that\n> we're stuck in some regard.  But maybe I'm being overly pessimistic\n> here, and it's really all a non-issue.  As I said earlier, it'd be\n> nice if others chimed in here.\n\nThinking about this a little more, we do have a proving ground.\nThat's what the whole pu/next/master construct is for.  So maybe this\nis a non-issue.  By the time it lands on master, we should have\ndecided whether the feature is worth keeping or not.\n\n-John\n"},{"id":"229079","messageId":"525ee8d5ba989_3983c19e7c8b@nysa.notmuch","threadId":"35120","inReplyTo":"20131016063436.GB24964@shrek.podlesie.net","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-16T19:28:21Z","receivedAt":"2013-10-16T19:28:21Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Krzysztof Mazur wrote:\n> On Tue, Oct 15, 2013 at 11:03:26PM -0500, Felipe Contreras wrote:\n> > > not some \"next\" behavior that may change in future.\n> > \n> > But I'm suggesting to add a core.addremove option as well, like you suggested,\n> > am I not?\n> \n> Yes, I think we both agreed on adding core.addremove. I'm just not\n> convinced if we should also add core.mode.\n\nIf we add core.addremove, all the issues you mentioned are solved. If we do\nthat, now the question is, how exactly does core.mode = next affect anybody\ngenatively? If you don't like it, you don't set it, that's why it's a\nconfiguration. I don't see the problem.\n\n> > So you would be happy if we had core.addremove = true *and* core.mode = next,\n> > right? You would use one, different people with different needs would use the\n> > other.\n> \n> Yes, if there are people that will use core.mode it will be worth\n> adding. I'm just not one of them.\n\nI am already using it.\n\n-- \nFelipe Contreras\n"},{"id":"229080","messageId":"525ee9872ab50_3983c19e7c27@nysa.notmuch","threadId":"35120","inReplyTo":"20131016070900.GC24964@shrek.podlesie.net","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-16T19:31:19Z","receivedAt":"2013-10-16T19:31:19Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Krzysztof Mazur wrote:\n> On Tue, Oct 15, 2013 at 10:55:07PM -0500, Felipe Contreras wrote:\n> > John Szakmeister wrote:\n> > > \n> > > I like the idea that we could kick git into a mode that applies the\n> > > behaviors we're talking about having in 2.0, but I'm concerned about\n> > > one aspect of it.  Not having these behaviors until 2.0 hits means\n> > > we're free to renege on our decisions in favor of something better, or\n> > > to pull out a bad idea.  But once we insert this knob, I don't know\n> > > that we have the same ability.  Once people realize it's there and\n> > > start using it, it gets harder to back out.  I guess we could maintain\n> > > the stance that \"the features are not concrete yet,\" or something like\n> > > that, but I think people would still get upset if something changes\n> > > out from under them.\n> > \n> > We cannot change the behavior of push.default = simple already, so at least\n> > that option is not in question.\n> \n> If we add core.addremove=true the same applies to it - we cannot remove\n> it later, the only we can do is to disable it by default in future\n> versions after testing (core.addremove=true or core.mode=next).\n\nThat is true, but adding core.addremove = true would probably imply there's the\noption of adding core.addremove = false.\n\n> > > So, at the end of the day, I'm just not sure it's worthwhile to have.\n> > \n> > This is exactly what happened on 1.6; nobody really tested the 'git foo'\n> > behavior, so we just switched from one version to the next. If you are not\n> > familiar with the outcome; it wasn't good.\n> \n> BTW, I'm still using pre-1.6 git-foo, I have /usr/libexec/git-core\n> in my PATH. So I would like to always have an option to disable some\n> new incompatible \"improvements\".\n\nThat's what core.addremove = false would do, wouldn't it?\n\n> > So I say we shouldn't just provide warnings, but also have an option to allow\n> > users (probably a minority) to start testing this.\n> > \n> \n> and an option to keep the old behavior, like we did with push.default.\n\nDitto.\n\n-- \nFelipe Contreras\n"},{"id":"229083","messageId":"525ee9d93c3af_3983c19e7caa@nysa.notmuch","threadId":"35120","inReplyTo":"CAEBDL5We2wshgMZcTXoDziXskKvb9s2=2DEZtXRBgbTiitCOZQ@mail.gmail.com","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-16T19:32:41Z","receivedAt":"2013-10-16T19:32:41Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"John Szakmeister wrote:\n> On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras\n> <felipe.contreras@gmail.com> wrote:\n> [snip]\n> > We cannot change the behavior of push.default = simple already, so at least\n> > that option is not in question.\n> \n> True.\n> \n> > Presumably you are worried about the other options that can't be enabled in any\n> > way.\n> \n> Yes.\n> \n> > But think about this; you are worried that if we add an *option* to enable this\n> > new behaviors, then we would be kind of forced to keep these behaviors. That\n> > seems to imply that you are proposing the current default; we wait until 2.0\n> > and not make it an *option*, but make it *default*.\n> >\n> > I think waiting until 2.0 to make it a default without evern having an option,\n> > and thus nobody actuallly testing this, is way worst than what I'm proposing;\n> > to add an option to start testing.\n> \n> My concern is that people don't treat it for what it is--a way to\n> experiment with the new behaviors--and then they get upset if we\n> discover that some behavior was not well thought out and it disappears\n> \"unexpectedly\" when we correct the matter.\n\nYes, but that's like removing the --force option in rm, because the user might\n\"unexpectedly\" remove files (s)he didn't intend to. If the user uses rm\n--force, the user must know what (s)he is doing, that's just the way it is.\n\nSimilarly, if a user does core.mode = next, the user is expecting to enable all\nfuture behaviors, because that's what core.mode = next does, if he doesn't want\nto do that, then why would he use that option?\n\nParticularily because there's push.default, and there would be core.addremove,\nand everything that core.mode = next does would be possible to do in other ways\nthat are not going to introduce new behavior as the version of Git advances.\n\n> We have a balance to strike: annoying users and getting some miles on the new\n> behaviors.  I see the technical end of this--your proposal to have a\n> 'core.mode'--but where is the non-technical end of this argument?  What\n> message are we proposing to send to the users?  What's our promise to them\n> surrounding core.mode and the new behaviors it offers?  Perhaps we don't have\n> much today that this affects, but what about tomorrow?  Are we saying that\n> behaviors enabled by core.mode=next are concrete (they're going in as-is, and\n> we won't alter their behavior before 2.0)?\n\nI'd say we make it explicit that if you turn on core.mode = next, the behavior\nyou experience is going to change from version to version. In other words,\nthere is no backwards compatibility promise for the behaviors core.mode = next\nenables. In a way it's kind of experimental, except that it's very likely the\nnew behavior won't be reverted back, just not 100% sure.\n\n> As I said, the only real drawback is that I see this as the latter,\n> because any other choice means users will get annoyed when something\n> changes out from under them.\n\nIf the user doesn't want things to change dramatically, the user shouldn't use\ncore.mode = next.\n\n> >> So, at the end of the day, I'm just not sure it's worthwhile to have.\n> >\n> > This is exactly what happened on 1.6; nobody really tested the 'git foo'\n> > behavior, so we just switched from one version to the next. If you are not\n> > familiar with the outcome; it wasn't good.\n> \n> You're right, I wasn't around for that.  And on the whole, I\n> absolutely agree: it's nice to get miles on these new\n> behaviors/features/etc.  I just worry that having an option like this\n> means we've committed to it,\n\nIt doesn't meant we are committed to it, because the behaviors in core.mode =\nnext have no promise to stay.\n\nEither way, these behaviors have been announce in each Git release for several\nreleases, and we are already warning the users that things will change in v2.0.\nI'd say that already means we've committed to it.\n\n> and I'm not sure that we want to give up the ability to change them without\n> having to go through some sort of deprecation cycle.  Or worse, we have to\n> wait until 3.0 and 2.0 hasn't even come out yet.\n\nI don't see why we would be giving up that ability.\n\n> I hope others chime in here.  And don't mistake me as dissenting; I'm\n> not.  And, I'm not assenting either.  I just want to know if you've\n> thought about what this means to users, and what we're prepared to\n> deal with.  Right now, I feel like half the argument around the option\n> is missing.\n\nOf course I've thought about that, otherwise I wouldn't have sent the patch.\n\nBut I have no hope of others chiming in.\n\n> > So I say we shouldn't just provide warnings, but also have an option to allow\n> > users (probably a minority) to start testing this.\n> \n> \"probably a minority\" -- I guess that's the part I disagree with.\n\nHow many people do you think want to start testing v2.0 behaviors? How many\npeople do you think will enable core.mode = next? I'd say the people that test\nrelease candidates are the minority, and I'd say the wants that would turn on\ncore.mode = next would be even less.\n\n> I'm not sure what a minority means here, but I don't think it'll be a handful\n> of people.  How big does that number get before we get concerned about\n> backlash from users if we decide to change course?\n\nI don't think it does matter, that's why I put the comment in parenthesis.\n\nIf 99% of users do 'rm --force' that doesn't make the --force option worst,\n--force means --force, and that's that.\n\nAnd core.mode = next doesn't include any promise of the new behaviors locked\nin, and that's that. Even if 100% enable core.mode = next, it would still mean\nno promise.\n\n> Or, is that simply not an issue?  Why or why not?  I have to be honest, if\n> the option was available, I'd have my developers turn it on.  I'm sure a\n> great deal of others would do so too.\n\nYou are welcome to do that, but then you should be aware there's a possibility\nthat if you rely on a v2.0 behavior, it might change.\n\nIf you are not willing to accept that caveat, then core.mode = next is not for\nyou. It's that simple.\n\n> Is there some other way we can solve this?  Having an experimental\n> branch with all the 2.0 features merged and those concerned can just\n> build that version?  I see the downside of that too: it's not as easy\n> for people to try, and there is nothing preventing folks from posting\n> binaries with the new behaviors enabled.\n\nI actually think we should have both. A branch were incomplete or potentially\ndangerous features are being worked on, but we have agreed they should be\nmerged eventually *and* a configuration option to turn v2.0 behavior.\n\nThe experimental branch would be clearly experimental, but that doesn't fullfil\nthe need of the v2.0 mode option, because the people that might to test this\ncould be end users that don't want to compile their own Git, they want to use\ntheir distro's git-1.9, just enable that option, and see how things fare.\n\n> It leads me to feeling that we're stuck in some regard.  But maybe I'm being\n> overly pessimistic here, and it's really all a non-issue.  As I said earlier,\n> it'd be nice if others chimed in here.\n\nWe are stuck, but not because we don't have options, but because these options\nwould never be realized. core.mode = next is one option, the experimental\nbranch is another option, and yet none of those are going to happen.\n\nAt the end of the day the collision course is set, and nobody would be testing\nthis stuff for v2.0 and the complaints will come in a similar way as they did\nin v1.6, probably less because this time we have warnings, and probably way\nless because the behaviors changes are very subtle, but exactly like in v1.6,\nnobody will test this behavior until v2.0 is release (except me, apparently).\n\nBut this is not what really worries me, what worries me is that we don't have\nenough changes for v2.0, we need more backwards incompatible change, and we\nneed to start testing it *now*, that way v2.0 will be better as it would\nintroduce more improvements, and the backwards incompatible changes would be\naccepted by the users. Alas, that's not going to happen. Change and Git don't\ngo together.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"229084","messageId":"525eef9ea46bd_3983c19e7c61@nysa.notmuch","threadId":"35120","inReplyTo":"CAEBDL5UaowCZggHijoqPF2UP5B6Y6Bkr9eP+A-Z3-x71W1Oi6Q@mail.gmail.com","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-16T19:57:18Z","receivedAt":"2013-10-16T19:57:18Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"John Szakmeister wrote:\n> On Wed, Oct 16, 2013 at 6:54 AM, John Szakmeister <john@szakmeister.net> wrote:\n> [snip]\n> > \"probably a minority\" -- I guess that's the part I disagree with.  I'm\n> > not sure what a minority means here, but I don't think it'll be a\n> > handful of people.  How big does that number get before we get\n> > concerned about backlash from users if we decide to change course?\n> > Or, is that simply not an issue?  Why or why not?  I have to be\n> > honest, if the option was available, I'd have my developers turn it\n> > on.  I'm sure a great deal of others would do so too.\n> >\n> > Is there some other way we can solve this?  Having an experimental\n> > branch with all the 2.0 features merged and those concerned can just\n> > build that version?  I see the downside of that too: it's not as easy\n> > for people to try, and there is nothing preventing folks from posting\n> > binaries with the new behaviors enabled.  It leads me to feeling that\n> > we're stuck in some regard.  But maybe I'm being overly pessimistic\n> > here, and it's really all a non-issue.  As I said earlier, it'd be\n> > nice if others chimed in here.\n> \n> Thinking about this a little more, we do have a proving ground.\n> That's what the whole pu/next/master construct is for.\n\nNo, that's not true.\n\n'next' doesn't contain experimental patches, it contains potentially dangerous\none that might benefit from some testing before going to master, but they are\ncertainly not experimental.\n\n'pu' doesn't contain experimental code either, the code in 'pu' has to be\nfeature complete. It might require a few more tunning patches, but it's not\nexperimental, and those branches are not long lived. For example the pack-v4\npatches could be merged today, and the people involved could keep working on\ntop of that merge point, but that doesn't happen, because 'pu' is not for\nexperimental stuff.\n\nThere is no place in the Git repository for pack-v4, because there's no place\nfor experimental patches.\n\n> So maybe this is a non-issue.  By the time it lands on master, we should have\n> decided whether the feature is worth keeping or not.\n\nI believe without an experimental branch, many branches would never mature to\ngo into master, or next, or even pu.\n\n-- \nFelipe Contreras\n"},{"id":"229101","messageId":"8629441933A94862982C5CDD6BF47690@PhilipOakley","threadId":"35120","inReplyTo":"525ee9d93c3af_3983c19e7caa@nysa.notmuch","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-10-16T22:02:41Z","receivedAt":"2013-10-16T22:02:41Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" <felipe.contreras@gmail.com>\n> John Szakmeister wrote:\n>> On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras\n>> <felipe.contreras@gmail.com> wrote:\n>> [snip]\n> Similarly, if a user does core.mode = next, the user is expecting to \n> enable all\n> future behaviors, because that's what core.mode = next does, if he \n> doesn't want\n> to do that, then why would he use that option?\n>\n\nWould this be a good time to suggest a specific wording should be \nproposed (or a reminder of what was proposed repeated) for the \ndocumentation of this option. It will be the documentation that users \nwill refer to when they need to know, rather than the list discussions.\n\nThe too and fro discussion suggested that it would be important to \npresent the chosen viewpoint well, so there would be no \nmisunderstanding, such that 'users' of the mode realise that they are \nacting as testers, and there are no promises for the posterity of any \ntrial behaviour, and they (the tester) have a 'caveat emptor' \nresponsibility. And that they need to keep up with developments (list & \nrelease notes) so that at any update they know what will disappear and \nappear without warning.\n\nPhilip\n\n> -- \n> Felipe Contreras\n> --\n"},{"id":"229106","messageId":"20131016230634.GO9464@google.com","threadId":"35120","inReplyTo":"8629441933A94862982C5CDD6BF47690@PhilipOakley","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-10-16T23:06:34Z","receivedAt":"2013-10-16T23:06:34Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Philip Oakley wrote:\n\n> Would this be a good time to suggest a specific wording should be\n> proposed (or a reminder of what was proposed repeated) for the\n> documentation of this option. It will be the documentation that\n> users will refer to when they need to know, rather than the list\n> discussions.\n\nIt's not clear to me that this config item is a good idea.\n\nWhat is the intended use?  If someone wants to test that their scripts\nwill continue to work with git 2.0, wouldn't testing a 2.0 release\ncandidate (or the current state of the 'jch' branch until one exists)\nbe the simplest way to do that?  If someone just likes the proposed\nbehavior changes and wants to start using them right away, maybe we\ncan help them by releasing 2.0 sooner ;-), or by advertising the\nfairly simple changes in commandline usage to get the new behaviors:\n\n\tInstead of \"git add\", use \"git add -A\".\n\n\tWhen using \"git add -u\" or \"git add -A\" from a subdirectory\n\tof the toplevel, specify \"git add -u .\" explicitly unless you\n\twant it to apply to the whole tree (in which case use\n\t\"git add -u :/\").\n\n\tInstead of letting \"git push\" guess, name the branch you\n\twant to push: \"git push origin master\".  Or set\n\t'[push] default = simple' in your configuration.\n\n\tPass --prefix to \"git svn clone\".\n\nThe downside of configuration like the proposed core.next is that it\nis hard to explain (\"What do you mean that I can't roll back to the\npre-2.0 behavior in Git 2.0 by setting this configuration setting to\nan appropriate value?\"), users or scripts can rely on it, and\nconfiguration variables tend to accumulate and never be removed.  If\nwe really want a run-time switch for this, I suspect an appropriately\nnamed environment variable would work better, since we have a history\nof being able to remove those without alarming people.\n\nMy two cents,\nJonathan\n"},{"id":"229130","messageId":"360782C85A2E4C9091EAD1E85D69680C@PhilipOakley","threadId":"35120","inReplyTo":"20131016230634.GO9464@google.com","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-10-17T19:48:46Z","receivedAt":"2013-10-17T19:48:46Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jonathan Nieder\" <jrnieder@gmail.com>\n> Philip Oakley wrote:\n>\n>> Would this be a good time to suggest a specific wording should be\n>> proposed (or a reminder of what was proposed repeated) for the\n>> documentation of this option. It will be the documentation that\n>> users will refer to when they need to know, rather than the list\n>> discussions.\n>\n> It's not clear to me that this config item is a good idea.\n>\n\nMy point was that the arguments had been rehearsed and explored, and \nthat it was possibly a suitable time for Filippe to update any commit \nmessage and config item documentation so that the proposal can be \njudged.\n\n> What is the intended use?  If someone wants to test that their scripts\n> will continue to work with git 2.0, wouldn't testing a 2.0 release\n> candidate (or the current state of the 'jch' branch until one exists)\n> be the simplest way to do that?  If someone just likes the proposed\n> behavior changes and wants to start using them right away, maybe we\n> can help them by releasing 2.0 sooner ;-), or by advertising the\n> fairly simple changes in commandline usage to get the new behaviors:\n>\n\nIn terms of moving forward, there needs to be a balance between being \nstuck in the old world of the 60's, and being projected into the bright \nnew world of the 20's (OK so I have exaggerated a bit there ;-). It's \nalways been a case of different strokes for different folks - there will \nbe folk who will try such an option (in an honest manner), who may not \nbe aware of branches that are outside of the regular pu / next / master \n/ maint branches which the project publicises.\n\nRather than letting the email discussion degenerate by going round in \ncircles to the usual end point, having a clarifying proposal (hopefully \nwell balanced) would at least allow a cleaner understanding and \ndecision.\n\n> Instead of \"git add\", use \"git add -A\".\n>\n> When using \"git add -u\" or \"git add -A\" from a subdirectory\n> of the toplevel, specify \"git add -u .\" explicitly unless you\n> want it to apply to the whole tree (in which case use\n> \"git add -u :/\").\n>\n> Instead of letting \"git push\" guess, name the branch you\n> want to push: \"git push origin master\".  Or set\n> '[push] default = simple' in your configuration.\n>\n> Pass --prefix to \"git svn clone\".\n>\n> The downside of configuration like the proposed core.next is that it\n> is hard to explain (\"What do you mean that I can't roll back to the\n> pre-2.0 behavior in Git 2.0 by setting this configuration setting to\n> an appropriate value?\"), users or scripts can rely on it, and\n> configuration variables tend to accumulate and never be removed.  If\n> we really want a run-time switch for this, I suspect an appropriately\n> named environment variable would work better, since we have a history\n> of being able to remove those without alarming people.\n>\n> My two cents,\n> Jonathan\n> \n"},{"id":"229144","messageId":"526051c3c2f07_448145fe74a@nysa.notmuch","threadId":"35120","inReplyTo":"20131016230634.GO9464@google.com","subject":"Re: [PATCH v3] Add core.mode configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-17T21:08:19Z","receivedAt":"2013-10-17T21:08:19Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jonathan Nieder wrote:\n> Philip Oakley wrote:\n> \n> > Would this be a good time to suggest a specific wording should be\n> > proposed (or a reminder of what was proposed repeated) for the\n> > documentation of this option. It will be the documentation that\n> > users will refer to when they need to know, rather than the list\n> > discussions.\n> \n> It's not clear to me that this config item is a good idea.\n> \n> What is the intended use?  If someone wants to test that their scripts\n> will continue to work with git 2.0, wouldn't testing a 2.0 release\n> candidate\n\nThere is no 2.0 release candidate, and the window between the first 2.0 rc and\n2.0 final is limited, such person might not have the time do such testing in\nthat window.\n\nMoreover, it's not just to test their scripts, but also their fingers.\n\n> (or the current state of the 'jch' branch until one exists)\n\nThat doesn't work for the vast majority of users who do not compile Git.\n\n> If someone just likes the proposed behavior changes and wants to start using\n> them right away, maybe we can help them by releasing 2.0 sooner ;-)\n\nSo basically you are advocating for another v1.6 fiasco, where users start\ncomplaining about the new behaviors *after* the release has been made, and\ntheir user experience has been broken. Is that the case?\n\n> , or by advertising the\n> fairly simple changes in commandline usage to get the new behaviors:\n> \n> \tInstead of \"git add\", use \"git add -A\".\n> \n> \tWhen using \"git add -u\" or \"git add -A\" from a subdirectory\n> \tof the toplevel, specify \"git add -u .\" explicitly unless you\n> \twant it to apply to the whole tree (in which case use\n> \t\"git add -u :/\").\n> \n> \tInstead of letting \"git push\" guess, name the branch you\n> \twant to push: \"git push origin master\".  Or set\n> \t'[push] default = simple' in your configuration.\n> \n> \tPass --prefix to \"git svn clone\".\n\nI don't get why you don't understand something so simple about human nature.\nEvery teach knows that you don't just give a lecture, even if the student\nunderstands what you explained, most likely (s)he would not learn it until\nafter doing excercises.\n\n99% of our users have not read the release notes about the 2.0 changes, 98%\nwill not read that advertizement you just said, 90% of those who read it will\nonly get noise, and the ones that read and understand it, might change their\nminds once they experience it.\n\nThat's why in every game conference they don't just explain to you the new\ngame, they let you play it, only then the end users can give an honest opinion\nabout the game.\n\nPerhaps it's unfortunate, but our users are human, and that's how humans work.\n\nWe don't know if our users would be OK with the 2.0 changes, it's only after\nthey have given it a try that they can honestly say, and it's better to give\nthem as much time as possible and make it easier for them to try.\n\n> The downside of configuration like the proposed core.next is that it\n> is hard to explain (\"What do you mean that I can't roll back to the\n> pre-2.0 behavior in Git 2.0 by setting this configuration setting to\n> an appropriate value?\"),\n\nIt is not hard to explain.\n\ncore.mode = next enables the proposed behavior for the next major version of\nGit (v2.0), which might change. core.mode = current (the default) enables the\nbehavior of the current version of Git (v1.x).\n\nIt is implied that there's no core.mode = previous, but it can be explicitly stated.\n\n> users or scripts can rely on it, and configuration variables tend to\n> accumulate and never be removed.\n\nNot this one, because this one makes it clear that is volatile (although\nprobably not that much).\n\n> If we really want a run-time switch for this, I suspect an appropriately\n> named environment variable would work better, since we have a history of\n> being able to remove those without alarming people.\n\nThe fact that B has done the job in the past, doesn't mean it would do the job\nbetter than A in the future.\n\n-- \nFelipe Contreras\n"}]}