{"thread":{"id":"26431","subject":"[PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","startedAt":"2011-02-07T02:27:23Z","lastAt":"2011-03-01T20:25:29Z","messageCount":25,"participants":["Nguyễn Thái Ngọc Duy","Junio C Hamano","Nguyen Thai Ngoc Duy","Miles Bader","Matthieu Moy","Joshua Juran","Sverre Rabbelier","Jakub Narebski","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"160570","messageId":"1297045643-26697-1-git-send-email-pclouds@gmail.com","threadId":"26431","inReplyTo":null,"subject":"[PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-07T02:27:23Z","receivedAt":"2011-02-07T02:27:23Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"When -u was introduced in dfdac5d (git-add -u: match the index with\nworking tree., 2007-04-20), \"add -u\" (without pathspec) added\neverything. Shortly after, 2ed2c22 (git-add -u paths... now works from\nsubdirectory, 2007-08-16) broke it while fixing something related.\n\nThis makes -u (and -A) inconsistent with some other options, namely -p.\nIt's been four years since the unintentional breakage and people are\nprobably used to \"git add -u\" updating only current directory. Perhaps\nit's time to bring the original behavior back? Current behavior can\nalways be achieved with \"git add -u .\"\n\nMigration plan:\n\nI'm bad at this. Can we start with a patch that warns users to do \"git\nadd -u .\" when they do \"git add -u\"? Hopefully they would have their\nfingers retraied by the time the behavior is changed in 1.8.0.\n\nPS. What about -A?\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n 2011/2/7 Sebastian Pipping :\n >> git add -u was tree-wide when it was introduced in dfdac5d (git-add\n >> -u: match the index with working tree., 2007-04-20), but 2ed2c22\n >> (git-add -u paths... now works from subdirectory, 2007-08-16) broke it\n >> while fixing something related.\n >\n > So my memory didn't fool me. Thanks for digging this out.\n >\n > Can we have tree-wide \"git add -u\" back, please?\n\n Yup yup I like it too (and wanted the original behavior sometimes, even\n though I didn't know it was original behavior).\n\n Pulling Junio in for -A. It seems closely related to -u. In fact I revert\n one line from 1e5f764 (builtin-add.c: optimize -A option and \"git add .\"\n - 2008-07-22) but not fully understand why it was changed.\n\n builtin/add.c | 7 +++++--\n t/t2200-add-update.sh | 13 +++++++------\n 2 files changed, 12 insertions(+), 8 deletions(-)\n\ndiff --git a/builtin/add.c b/builtin/add.c\nindex 12b964e..f1f8b5a 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -389,7 +389,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \t\tdie(\"-A and -u are mutually incompatible\");\n \tif (!show_only && ignore_missing)\n \t\tdie(\"Option --ignore-missing can only be used together with --dry-run\");\n-\tif ((addremove || take_worktree_changes) && !argc) {\n+\tif (addremove && !argc) {\n \t\tstatic const char *here[2] = { \".\", NULL };\n \t\targc = 1;\n \t\targv = here;\n@@ -412,7 +412,10 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \t\tfprintf(stderr, \"Maybe you wanted to say 'git add .'?\\n\");\n \t\treturn 0;\n \t}\n-\tpathspec = validate_pathspec(argc, argv, prefix);\n+\tif (take_worktree_changes && !argc)\n+\t\tpathspec = NULL;\n+\telse\n+\t\tpathspec = validate_pathspec(argc, argv, prefix);\n \n \tif (read_cache() < 0)\n \t\tdie(\"index file corrupt\");\ndiff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh\nindex 0692427..2201242 100755\n--- a/t/t2200-add-update.sh\n+++ b/t/t2200-add-update.sh\n@@ -69,15 +69,16 @@ test_expect_success 'cache tree has not been corrupted' '\n test_expect_success 'update from a subdirectory' '\n \t(\n \t\tcd dir1 &&\n-\t\techo more >sub2 &&\n+\t\techo more >>sub2 &&\n \t\tgit add -u sub2\n-\t)\n-'\n-\n-test_expect_success 'change gets noticed' '\n-\n+\t) &&\n \ttest \"$(git diff-files --name-status dir1)\" = \"\"\n+'\n \n+test_expect_success 'update without args from subdir' '\n+\techo more >>top &&\n+\t( cd dir1 && git add -u ) &&\n+\ttest \"$(git diff-files --name-status top)\" = \"\"\n '\n \n test_expect_success SYMLINKS 'replace a file with a symlink' '\n-- \n1.7.3.4.878.g439c7\n"},{"id":"160580","messageId":"7vsjw0v11p.fsf@alter.siamese.dyndns.org","threadId":"26431","inReplyTo":"1297045643-26697-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-07T05:58:10Z","receivedAt":"2011-02-07T05:58:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> When -u was introduced in dfdac5d (git-add -u: match the index with\n> working tree., 2007-04-20), \"add -u\" (without pathspec) added\n> everything. Shortly after, 2ed2c22 (git-add -u paths... now works from\n> subdirectory, 2007-08-16) broke it while fixing something related.\n\nAs long as the command takes pathspecs, it should never be tree-wide.\nMaking it tree-wide when there is no pathspec is even worse.\n\nIf \"add -p\" does not limit operation to the current directory, probably\nthat is the inconsistency bug to be fixed.\n"},{"id":"160581","messageId":"AANLkTimG6s5vSCnisJCt-EXkcJGXfY4Y3WtdB_netU08@mail.gmail.com","threadId":"26431","inReplyTo":"7vsjw0v11p.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-07T06:14:36Z","receivedAt":"2011-02-07T06:14:36Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 7, 2011 at 12:58 PM, Junio C Hamano wrote:\n> Nguyễn Thái Ngọc Duy   writes:\n>\n>> When -u was introduced in dfdac5d (git-add -u: match the index with\n>> working tree., 2007-04-20), \"add -u\" (without pathspec) added\n>> everything. Shortly after, 2ed2c22 (git-add -u paths... now works from\n>> subdirectory, 2007-08-16) broke it while fixing something related.\n>\n> As long as the command takes pathspecs, it should never be tree-wide.\n> Making it tree-wide when there is no pathspec is even worse.\n\ngit log -p and diff family all can take pathspecs. All default to\ntree-wide without pathspecs. This is what I'm doing all the time:\n\ngit diff\n# checking, ok, looks good\ngit add -u\n# ack, need to come to root dir first\n-- \nDuy\n"},{"id":"160582","messageId":"buo8vxsfjib.fsf@dhlpc061.dev.necel.com","threadId":"26431","inReplyTo":"AANLkTimG6s5vSCnisJCt-EXkcJGXfY4Y3WtdB_netU08@mail.gmail.com","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-07T06:26:04Z","receivedAt":"2011-02-07T06:26:04Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Nguyen Thai Ngoc Duy writes:\n> git log -p and diff family all can take pathspecs. All default to\n> tree-wide without pathspecs. This is what I'm doing all the time:\n>\n> git diff\n> # checking, ok, looks good\n> git add -u\n> # ack, need to come to root dir first\n\nNot to mention \"git status\", which shows everything in the tree when\ngiven no args, but will only show changes underneath the cwd if given\n\".\" as an argument.\n\nI agree that the \"default to root of git dir when given no args\"\nbehavior seems both more convenient -- it's annoying to specify the root\nof the tree explicitly, but very easy to specify the cwd explicitly\n(\".\") -- and more intuitive -- If I want \"everything underneath cwd\",\nI'll naturually specify \".\" as an argument; if I give no args, I almost\ncertainly want the whole tree, no matter where I happen to be in it.\n\n-Miles\n\n-- \nChristian, n. One who follows the teachings of Christ so long as they are not\ninconsistent with a life of sin.\n"},{"id":"160602","messageId":"vpq1v3kf3m8.fsf@bauges.imag.fr","threadId":"26431","inReplyTo":"7vsjw0v11p.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-07T12:09:19Z","receivedAt":"2011-02-07T12:09:19Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"[ Your mailer did something strange with my name and email ]\n\nJunio C Hamano writes:\n\n> Nguyễn Thái Ngọc Duy writes:\n>\n>> When -u was introduced in dfdac5d (git-add -u: match the index with\n>> working tree., 2007-04-20), \"add -u\" (without pathspec) added\n>> everything. Shortly after, 2ed2c22 (git-add -u paths... now works from\n>> subdirectory, 2007-08-16) broke it while fixing something related.\n>\n> As long as the command takes pathspecs, it should never be tree-wide.\n> Making it tree-wide when there is no pathspec is even worse.\n\nThis is against the common use in Git. As I mentionned in the other\nthread, pretty much any git command taking an optional pathspec is\nstill tree-wide when called without argument. \"git add -u\" is the\nexception.\n\n> If \"add -p\" does not limit operation to the current directory, probably\n> that is the inconsistency bug to be fixed.\n\nAdd \"git log\", \"git status\", \"git commit\", \"git show\", \"git diff\", and\na few others I've missed to the list of \"exceptions\" ...\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160744","messageId":"9CBA512E-D62E-483C-BEBD-D9E41083756E@gmail.com","threadId":"26431","inReplyTo":"AANLkTimG6s5vSCnisJCt-EXkcJGXfY4Y3WtdB_netU08@mail.gmail.com","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Joshua Juran","fromEmail":"jjuran@gmail.com","sentAt":"2011-02-09T10:58:15Z","receivedAt":"2011-02-09T10:58:15Z","isPatch":true,"sender":{"key":"jjuran@gmail.com","avatar":null},"body":"On Feb 6, 2011, at 10:14 PM, Nguyen Thai Ngoc Duy wrote:\n\n> On Mon, Feb 7, 2011 at 12:58 PM, Junio C Hamano \n> wrote:\n>> Nguyễn Thái Ngọc Duy writes:\n>>\n>>> When -u was introduced in dfdac5d (git-add -u: match the index with\n>>> working tree., 2007-04-20), \"add -u\" (without pathspec) added\n>>> everything. Shortly after, 2ed2c22 (git-add -u paths... now works \n>>> from\n>>> subdirectory, 2007-08-16) broke it while fixing something related.\n>>\n>> As long as the command takes pathspecs, it should never be tree-wide.\n>> Making it tree-wide when there is no pathspec is even worse.\n>\n> git log -p and diff family all can take pathspecs. All default to\n> tree-wide without pathspecs. This is what I'm doing all the time:\n>\n> git diff\n> # checking, ok, looks good\n> git add -u\n> # ack, need to come to root dir first\n\nThe only reason I'm not routinely bitten by this is that I'm generally \nalways at the root of the tree. But I certainly *think* about it as \nan operation that's tree-wide, not local. If I meant to limit the \nscope, I'd specify a path.\n\nJosh\n"},{"id":"162351","messageId":"7vei6t4uwa.fsf@alter.siamese.dyndns.org","threadId":"26431","inReplyTo":"1297045643-26697-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-27T10:46:45Z","receivedAt":"2011-02-27T10:46:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> Migration plan:\n>\n> I'm bad at this. Can we start with a patch that warns users to do \"git\n> add -u .\" when they do \"git add -u\"? Hopefully they would have their\n> fingers retraied by the time the behavior is changed in 1.8.0.\n\nPerhaps in this order:\n\nStep 1, as soon as possible:\n\n * Introduce \"static int make_update_global;\" file scope static to\n builtin/add.c and default to 0;\n\n * Introduce \"add.make_update_global\" configuration variable, and toggle\n the above variable when it is explicitly given; also record the fact\n that you actually saw this variable in the config parser regardless of\n the value that is given;\n\n * Document the configuration variable as a new feature, without\n indicating that that will be the new default in the future, but\n strongly recommending that existing scripts should be updated and new\n scripts should be written the variable in mind---namely, their use of\n \"add -u\" should use \".\" if they are relying on the current \"limit to\n cwd\" behaviour.\n\n * Ship this as 1.7.X and see how well the new feature is accepted in the\n wider user community. If the feature is not widely used, there is no\n point in proceeding further.\n\nStep 2, two cycles (i.e. 6-8 months) before 1.8.0, provided if the\nprevious step is proven positive:\n\n * When \"git add -u\" is run without any pathspec, and when the user does\n not have the configuration variable, warn loudly that the default\n behaviour will change in 1.8.0, and tell the users that the current\n behaviour is still available by setting the configuration variable.\n\nStep 3, at 1.8.0 and probably one or two more cycles:\n\n * When \"git add -u\" is run without any pathspec, and when the user does\n not have the configuration variable, warn loudly that the default\n behaviour _has_ changed in 1.8.0, to help people who migrated from\n early 1.7.X before Step 2 directly to 1.8.X series.\n\nStep 4, 3 cycles after 1.8.0:\n\n * Drop the warning.\n\n> PS. What about -A?\n\nI personally think it should change exactly the same way as \"-u\" for\nconsistency, but I had the impression that the list concensus was to keep\nthe current behaviour.\n\nHas anybody been keeping tallies on the discussion around\n\n http://thread.gmane.org/gmane.comp.version-control.git/166135/focus=166457\n\nWe seem to have lost track. All I recall was that I changed my mind and\nmigrated from the third camp (the command defaults to whichever somebody\nthought would be more convenient, lacking consistency across command set)\nto \"it would be more convenient to default to full-tree when there is no\npathspec, as limiting to cwd with '.' is easier\" camp myself, but the\ndiscussion is not about my personal preference but about seeing if we have\nan overwhelming majority consensus, so...\n"},{"id":"162359","messageId":"vpqoc5x4saj.fsf@bauges.imag.fr","threadId":"26431","inReplyTo":"7vei6t4uwa.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-27T11:43:00Z","receivedAt":"2011-02-27T11:43:00Z","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> Step 2, two cycles (i.e. 6-8 months) before 1.8.0, provided if the\n> previous step is proven positive:\n>\n> * When \"git add -u\" is run without any pathspec, and when the user does\n> not have the configuration variable, warn loudly that the default\n> behaviour will change in 1.8.0,\n\nI'd even say \"error out\", since the old behavior is still easily\navailable with \"git add -u .\" (which should be mentionned in the\nwarning/error message).\n\n>> PS. What about -A?\n>\n> I personally think it should change exactly the same way as \"-u\" for\n> consistency,\n\nSame here. I care less since I use \"add -A\" less, but both commands\nshould really behave the same since they're very similar.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"162360","messageId":"AANLkTimox7NhBsp9V=9p4hooeB-sprV21UbUFtzf+-Rw@mail.gmail.com","threadId":"26431","inReplyTo":"7vei6t4uwa.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-27T13:35:15Z","receivedAt":"2011-02-27T13:35:15Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sun, Feb 27, 2011 at 11:46, Junio C Hamano wrote:\n>  * Ship this as 1.7.X and see how well the new feature is accepted in the\n>   wider user community.  If the feature is not widely used, there is no\n>   point in proceeding further.\n\nI'm confused, I thought we were doing this for consistency reasons?\nThat would benefit mostly new users, right? New users, which are\nunlikely to notice this new feature, or report to this list that they\nfind it useful?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"162373","messageId":"AANLkTi=BwTHRWcUu26VLWAhFupmuJpu8fvOF98--HJ5f@mail.gmail.com","threadId":"26431","inReplyTo":"7vei6t4uwa.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-27T16:52:34Z","receivedAt":"2011-02-27T16:52:34Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sun, Feb 27, 2011 at 5:46 PM, Junio C Hamano wrote:\n> Perhaps in this order:\n>\n> Step 1, as soon as possible:\n>\n>  * Introduce \"add.make_update_global\" configuration variable, and toggle\n>   the above variable when it is explicitly given; also record the fact\n>   that you actually saw this variable in the config parser regardless of\n>   the value that is given;\n\nErmm.. compat.make_update_global, with the intent that the config will\nbe dropped in future (1.9.0 maybe)?\n\n>  * Document the configuration variable as a new feature, without\n>   indicating that that will be the new default in the future, but\n>   strongly recommending that existing scripts should be updated and new\n>   scripts should be written the variable in mind---namely, their use of\n>   \"add -u\" should use \".\" if they are relying on the current \"limit to\n>   cwd\" behaviour.\n\nThere's a problem. I use git on many machines. Some will have this\nconfig enabled, some will not (yet). Perhaps a third option, which\nwill print something when \"git add -u\" is issued as a reminder? I\ndon't know. What I need is to notice old behavior of \"git add -u\"\nbefore it's too late.\n\n> Step 4, 3 cycles after 1.8.0:\n>\n>  * Drop the warning.\n\nStep 5 (1.9.0 or later):\n\n * Drop compat.make_update_global.\n-- \nDuy\n"},{"id":"162375","messageId":"AANLkTimO8U5Lp7GkMf0K_v5hKvBktfEbnZTW=AZn_71u@mail.gmail.com","threadId":"26431","inReplyTo":"AANLkTimox7NhBsp9V=9p4hooeB-sprV21UbUFtzf+-Rw@mail.gmail.com","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-27T17:01:55Z","receivedAt":"2011-02-27T17:01:55Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sun, Feb 27, 2011 at 8:35 PM, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Sun, Feb 27, 2011 at 11:46, Junio C Hamano wrote:\n>>  * Ship this as 1.7.X and see how well the new feature is accepted in the\n>>   wider user community.  If the feature is not widely used, there is no\n>>   point in proceeding further.\n>\n> I'm confused, I thought we were doing this for consistency reasons?\n> That would benefit mostly new users, right? New users, which are\n> unlikely to notice this new feature, or report to this list that they\n> find it useful?\n\nI think the purpose is to see if this benefits current user base\nfirst, which is large enough. If it beats the user base hard, it's not\nworth adding even for consistency. Unfortunately not all of us users\nreads release notes. I don't know how we know it's widely used.\nPutting something like this in docs?\n\n\"This is experimental. If you use it and like it, raise your voice in git@ver\"\n-- \nDuy\n"},{"id":"162376","messageId":"AANLkTim9EOHBtZj5h1+xs9C_WhpcycwoPbWZHrZ38w+E@mail.gmail.com","threadId":"26431","inReplyTo":"vpqoc5x4saj.fsf@bauges.imag.fr","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-27T17:04:40Z","receivedAt":"2011-02-27T17:04:40Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sun, Feb 27, 2011 at 6:43 PM, Matthieu Moy\n wrote:\n> Junio C Hamano writes:\n>\n>> Step 2, two cycles (i.e. 6-8 months) before 1.8.0, provided if the\n>> previous step is proven positive:\n>>\n>>  * When \"git add -u\" is run without any pathspec, and when the user does\n>>    not have the configuration variable, warn loudly that the default\n>>    behaviour will change in 1.8.0,\n>\n> I'd even say \"error out\", since the old behavior is still easily\n> available with \"git add -u .\" (which should be mentionned in the\n> warning/error message).\n\nYou wouldn't want scripts to break this way. Warnings can give script\nwriters some time to update (assume that scripts are installed system\nwide, not in $HOME).\n-- \nDuy\n"},{"id":"162380","messageId":"7vy6512rnb.fsf@alter.siamese.dyndns.org","threadId":"26431","inReplyTo":"AANLkTi=BwTHRWcUu26VLWAhFupmuJpu8fvOF98--HJ5f@mail.gmail.com","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-27T19:39:52Z","receivedAt":"2011-02-27T19:39:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n\n> On Sun, Feb 27, 2011 at 5:46 PM, Junio C Hamano wrote:\n>> Perhaps in this order:\n>>\n>> Step 1, as soon as possible:\n>>\n>>  * Introduce \"add.make_update_global\" configuration variable, and toggle\n>>   the above variable when it is explicitly given; also record the fact\n>>   that you actually saw this variable in the config parser regardless of\n>>   the value that is given;\n>\n> Ermm.. compat.make_update_global, with the intent that the config will\n> be dropped in future (1.9.0 maybe)?\n\nAs you haven't yet proven that this \"new feature\" is even useful to help\nnew people nor existing users at this step, you cannot claim \"we plan to\ndrop this in the future\", hence naming it \"compat.*\" is a no-go. During\nthis step, we can not even say \"we plan to make this the default\"; we\nwould confuse the users otherwise (it is fine to say \"we might make this\nthe default some day\").\n\nEven if we indeed end up proceeding to step 2, I don't see a point in\nplanning to drop the support from the beginning. We might end up doing\nso, but we can decide when that becomes necessary, and that would be long\nafter the tree-wide default proves a reasonable one, and preferably after\nseeing a new person or two raise \"what's the point of making 'add -u'\nrestricted to cwd? we have too many options and this can go\" on the list.\n\nThen we would start deprecating the config, giving a warning when people\nwho still rely on their \"add.make_update_global = false\" say \"add -u\"\nwithout pathspec in a few cycles, and then finally drop it at a version\nbump boundary.\n\n> There's a problem. I use git on many machines. Some will have this\n> config enabled, some will not (yet). Perhaps a third option, which\n> will print something when \"git add -u\" is issued as a reminder?\n\nSuch a warning would not help you on a machine that does not even have git\nwith Step 1 change.\n\nWhat you conceive as a problem is just a reminder that any incompatible\nchange you plan to add will have pain involved. On two machines, one with\na new feature and the other without the new feature, you would have to\nwork differently _or_ you would train yourself to use both versions in a\ncompatible way (e.g. when you mean tree-wide, you would cdup, and when you\nmean cwd, you would explicitly say \".\", from the command line). That is\nnot limited to this particular feature but any incompatible change, no?\n"},{"id":"162397","messageId":"AANLkTimqBxhHBVzet9M-6AqiCp664hkroM9QWS_1SiLP@mail.gmail.com","threadId":"26431","inReplyTo":"7vy6512rnb.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-28T06:37:54Z","receivedAt":"2011-02-28T06:37:54Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 28, 2011 at 2:39 AM, Junio C Hamano wrote:\n> Nguyen Thai Ngoc Duy writes:\n>> There's a problem. I use git on many machines. Some will have this\n>> config enabled, some will not (yet). Perhaps a third option, which\n>> will print something when \"git add -u\" is issued as a reminder?\n>\n> Such a warning would not help you on a machine that does not even have git\n> with Step 1 change.\n>\n> What you conceive as a problem is just a reminder that any incompatible\n> change you plan to add will have pain involved.  On two machines, one with\n> a new feature and the other without the new feature, you would have to\n> work differently _or_ you would train yourself to use both versions in a\n> compatible way (e.g. when you mean tree-wide, you would cdup, and when you\n> mean cwd, you would explicitly say \".\", from the command line).  That is\n> not limited to this particular feature but any incompatible change, no?\n\nNo. But I hoped it would help me somehow, or at least remind me to\nupdate git on the machines I touch.\n-- \nDuy\n"},{"id":"162401","messageId":"7vk4gkk5pd.fsf@alter.siamese.dyndns.org","threadId":"26431","inReplyTo":"AANLkTimqBxhHBVzet9M-6AqiCp664hkroM9QWS_1SiLP@mail.gmail.com","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-28T06:56:30Z","receivedAt":"2011-02-28T06:56:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n\n> On Mon, Feb 28, 2011 at 2:39 AM, Junio C Hamano wrote:\n> ...\n>> What you conceive as a problem is just a reminder that any incompatible\n>> change you plan to add will have pain involved....\n>\n> No. But I hoped it would help me somehow, or at least remind me to\n> update git on the machines I touch.\n\nPerhaps the migration plan is not helpful enough? If that is the case we\nwould need to rethink it to be even less impactful.\n\nI already do not like the possibility of potential double deprecation\nmyself, one to flip the default and then possibly another to drop the\nsupport of the traditional behavour, but anything I've seen so far would\nhurt the end users more than that plan.\n"},{"id":"162540","messageId":"AANLkTimRuUdGsgkt63PspvNXXjusZeOJWMhSXQ5nS81t@mail.gmail.com","threadId":"26431","inReplyTo":"7vk4gkk5pd.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-01T11:22:24Z","receivedAt":"2011-03-01T11:22:24Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 28, 2011 at 1:56 PM, Junio C Hamano wrote:\n> Perhaps the migration plan is not helpful enough?  If that is the case we\n> would need to rethink it to be even less impactful.\n\nBut how many people may be impacted this way? If it's few, probably\nnot worth the headaches. I want to believe the number is few, but I\nthink anybody who ssh to some machine may have the same problem\nbecause they may not control what's in that machine.\n\nI can only think of another way, ugly though: add a new command name,\nsay \"nad\", that goes with new behavior, \"add\" remains old school. This\nway if I mistakenly type 'nad' on unsupported git, it refuses and I'm\nsafe. Whether the new name is temporary (until the behavior flip in\n\"add\") or permanent is another ugly matter to think about.\n\nOr accept that evolution is painful and go with current plan, which I'm OK too.\n-- \nDuy\n"},{"id":"162548","messageId":"7v1v2reywi.fsf@alter.siamese.dyndns.org","threadId":"26431","inReplyTo":"AANLkTimRuUdGsgkt63PspvNXXjusZeOJWMhSXQ5nS81t@mail.gmail.com","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-01T13:46:53Z","receivedAt":"2011-03-01T13:46:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n\n> On Mon, Feb 28, 2011 at 1:56 PM, Junio C Hamano wrote:\n>\n> But how many people may be impacted this way? ...\n> Or accept that evolution is painful and go with current plan, which I'm OK too.\n\nSo even though you raised a concern on possible pains during the\nmigration, you think that the migration plan outlined would be the\nleast bad one?\n"},{"id":"162549","messageId":"AANLkTikLJXyQH8au5SpfvAMgq3sA1PqKsG16GK0YcCFB@mail.gmail.com","threadId":"26431","inReplyTo":"7v1v2reywi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-01T14:15:21Z","receivedAt":"2011-03-01T14:15:21Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 1, 2011 at 8:46 PM, Junio C Hamano wrote:\n> Nguyen Thai Ngoc Duy writes:\n>\n>> On Mon, Feb 28, 2011 at 1:56 PM, Junio C Hamano wrote:\n>>\n>> But how many people may be impacted this way? ...\n>> Or accept that evolution is painful and go with current plan, which I'm OK too.\n>\n> So even though you raised a concern on possible pains during the\n> migration, you think that the migration plan outlined would be the\n> least bad one?\n\nI only see two ways. The 'new command' approach only delays the\ntransition until a later (user decided) point. There's no guarantee\nthat I (user) would make a good decision to switch. Plus the outlined\nplan looks simpler. Yes, it seems better.\n-- \nDuy\n"},{"id":"162552","messageId":"vpqipw2rixy.fsf@bauges.imag.fr","threadId":"26431","inReplyTo":"7vk4gkk5pd.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-03-01T14:53:13Z","receivedAt":"2011-03-01T14:53:13Z","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 already do not like the possibility of potential double deprecation\n> myself, one to flip the default and then possibly another to drop the\n> support of the traditional behavour, but anything I've seen so far would\n> hurt the end users more than that plan.\n\nI think promoting \"git add -u .\" more than a configuration option would\nreduce the pain.\n\nAs a user, if I get used to typing \"git add -u .\" instead of \"git add -u\", \nI get the current behavior regardless of the version of Git, without a\nwarning. Later, when all the machines I word on support the tree-wide\n\"git add -u\" (either 1.7.x + some configuration or 1.8.y), I'll use it\nas a new feature.\n\nSo, a warning like\n\n warning: the behavior of \"git add -u\" without pathspec will change in\n Git 1.8.0. To keep the current behavior, use this instead:\n \n git add -u .\n \n + explanations about the config options as already discussed here\n\nwould be fine.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"162565","messageId":"7vd3maelbh.fsf@alter.siamese.dyndns.org","threadId":"26431","inReplyTo":"vpqipw2rixy.fsf@bauges.imag.fr","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-01T18:40:18Z","receivedAt":"2011-03-01T18:40:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> I think promoting \"git add -u .\" more than a configuration option would\n> reduce the pain.\n\nYeah, I tend to agree.\n\n> As a user, if I get used to typing \"git add -u .\" instead of \"git add -u\", \n> I get the current behavior regardless of the version of Git, without a\n> warning. Later, when all the machines I word on support the tree-wide\n> \"git add -u\" (either 1.7.x + some configuration or 1.8.y), I'll use it\n> as a new feature.\n\nOnce your users (you as a script writer) have an option to set the\nconfiguration to participate in the tree-wide party early, you would need\nto update your scripts immediately so that they don't break on them; so\nthe introduction of the configuration becomes a flag-day event. Hmph...\n\n> So, a warning like\n>\n> warning: the behavior of \"git add -u\" without pathspec will change in\n> Git 1.8.0. To keep the current behavior, use this instead:\n> \n> git add -u .\n> \n> + explanations about the config options as already discussed here\n>\n> would be fine.\n\nYeah, I think you convinced me that an elaborate configuration wouldn't\nhelp us at all. We just keep warning in 1.7.x series when \"add -u\" didn't\nsee any pathspec, and flip the default at 1.8.0\n\nSimpler and cleaner ;-)\n"},{"id":"162566","messageId":"vpq4o7mfzd1.fsf@bauges.imag.fr","threadId":"26431","inReplyTo":"7vd3maelbh.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-03-01T18:51:38Z","receivedAt":"2011-03-01T18:51:38Z","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>> I think promoting \"git add -u .\" more than a configuration option would\n>> reduce the pain.\n>\n> Yeah, I tend to agree.\n>\n>> As a user, if I get used to typing \"git add -u .\" instead of \"git add -u\", \n>> I get the current behavior regardless of the version of Git, without a\n>> warning. Later, when all the machines I word on support the tree-wide\n>> \"git add -u\" (either 1.7.x + some configuration or 1.8.y), I'll use it\n>> as a new feature.\n>\n> Once your users (you as a script writer) have an option to set the\n> configuration to participate in the tree-wide party early, you would need\n> to update your scripts immediately so that they don't break on them;\n\nBut \"update\" should mean \"replace git add -u with git add -u .\", which\nis the portable way to do the same.\n\n> so the introduction of the configuration becomes a flag-day event.\n> Hmph...\n\nThe introduction of the config variable is a non-event if you already\nuse the portable . notation.\n\n>> So, a warning like\n>>\n>> warning: the behavior of \"git add -u\" without pathspec will change in\n>> Git 1.8.0. To keep the current behavior, use this instead:\n>> \n>> git add -u .\n>> \n>> + explanations about the config options as already discussed here\n>>\n>> would be fine.\n>\n> Yeah, I think you convinced me that an elaborate configuration wouldn't\n> help us at all. We just keep warning in 1.7.x series when \"add -u\" didn't\n> see any pathspec, and flip the default at 1.8.0\n>\n> Simpler and cleaner ;-)\n\nI think is still makes sense to have a config variable, so that people\nwho want the new behavior can get it ASAP. Right after 1.8 is out, I'll\nstill have machines where I'm too lazy to install a brand new Git, and\nI'll want to get the 1.8 goodness for free ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"162571","messageId":"m3oc5u7hy9.fsf@localhost.localdomain","threadId":"26431","inReplyTo":"vpq4o7mfzd1.fsf@bauges.imag.fr","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-03-01T19:36:35Z","receivedAt":"2011-03-01T19:36:35Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthieu Moy writes:\n> Junio C Hamano writes:\n>> Matthieu Moy writes:\n\n[...]\n>>> So, a warning like\n>>>\n>>> warning: the behavior of \"git add -u\" without pathspec will change in\n>>> Git 1.8.0. To keep the current behavior, use this instead:\n>>> \n>>> git add -u .\n>>> \n>>> + explanations about the config options as already discussed here\n>>>\n>>> would be fine.\n>>\n>> Yeah, I think you convinced me that an elaborate configuration wouldn't\n>> help us at all. We just keep warning in 1.7.x series when \"add -u\" didn't\n>> see any pathspec, and flip the default at 1.8.0\n>>\n>> Simpler and cleaner ;-)\n> \n> I think is still makes sense to have a config variable, so that people\n> who want the new behavior can get it ASAP. Right after 1.8 is out, I'll\n> still have machines where I'm too lazy to install a brand new Git, and\n> I'll want to get the 1.8 goodness for free ;-).\n\nSo it would be the opposite of compat.*; for example `future.wholeTree`\nconfig variable? ;-)\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"162577","messageId":"20110301200025.GF10082@sigill.intra.peff.net","threadId":"26431","inReplyTo":"vpq4o7mfzd1.fsf@bauges.imag.fr","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-01T20:00:25Z","receivedAt":"2011-03-01T20:00:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 01, 2011 at 07:51:38PM +0100, Matthieu Moy wrote:\n\n> > Once your users (you as a script writer) have an option to set the\n> > configuration to participate in the tree-wide party early, you would need\n> > to update your scripts immediately so that they don't break on them;\n> \n> But \"update\" should mean \"replace git add -u with git add -u .\", which\n> is the portable way to do the same.\n> \n> > so the introduction of the configuration becomes a flag-day event.\n> > Hmph...\n> \n> The introduction of the config variable is a non-event if you already\n> use the portable . notation.\n\nRight. Once this happens, you can never say \"git add -u\" again portably.\nYou can't rely on the old behavior, because it's changing. You can't\nrely on the new behavior, because you might be using an old version. So\nas a script you _must_ say \"git add -u .\", and if you want top-level\nbehavior and are not at the top-level, you must cd to the toplevel and\n\"add .\". Which sounds onerous, but it is what scripts have to do\nalready with the current behavior.\n\n> > Yeah, I think you convinced me that an elaborate configuration wouldn't\n> > help us at all. We just keep warning in 1.7.x series when \"add -u\" didn't\n> > see any pathspec, and flip the default at 1.8.0\n> >\n> > Simpler and cleaner ;-)\n> \n> I think is still makes sense to have a config variable, so that people\n> who want the new behavior can get it ASAP. Right after 1.8 is out, I'll\n> still have machines where I'm too lazy to install a brand new Git, and\n> I'll want to get the 1.8 goodness for free ;-).\n\nAgreed. I also think there should be a setting to keep the current\nbehavior. I don't want to use it, but given that configuration does not\nintroduce any existing portability issues, we can help people who really\nliked the old behavior. We are inconveniencing them by changing the\ndefault, but it seems doubly mean to leave them with no way of restoring\nit short of typing extra characters on every invocation.\n\n-Peff\n"},{"id":"162580","messageId":"7vzkped2hk.fsf@alter.siamese.dyndns.org","threadId":"26431","inReplyTo":"vpq4o7mfzd1.fsf@bauges.imag.fr","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-01T20:12:23Z","receivedAt":"2011-03-01T20:12:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> But \"update\" should mean \"replace git add -u with git add -u .\", which\n> is the portable way to do the same.\n>\n>> so the introduction of the configuration becomes a flag-day event.\n>> Hmph...\n>\n> The introduction of the config variable is a non-event if you already\n> use the portable . notation.\n\nI think you got this part wrong. Until now, there was no \"portability\" to\nworry about when using \"git add -u\". \"git add -u\" used to be _guaranteed_\nto be relative to the cwd, with or without \".\". Our update will _break_\nthat expectation and suddenly make \".\" \"the portable notation\".\n\nIn other words, it is far from a non-event. We cannot say \"'add -u .' is\nthe portable way to write it anyway, so you should have been writing that\nfrom day one\" as an excuse for breaking their scripts.\n\nWe still have to say \"We are sorry, we will be breaking your scripts.\nPlease add an extra dot at the end\". I am Ok saying that, but we should\nadmit that we are knowingly breaking things.\n"},{"id":"162581","messageId":"vpqvd02a8qu.fsf@bauges.imag.fr","threadId":"26431","inReplyTo":"7vzkped2hk.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1.8.0] add: make \"add -u\" update full tree without pathspec","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-03-01T20:25:29Z","receivedAt":"2011-03-01T20:25:29Z","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>> But \"update\" should mean \"replace git add -u with git add -u .\", which\n>> is the portable way to do the same.\n>>\n>>> so the introduction of the configuration becomes a flag-day event.\n>>> Hmph...\n>>\n>> The introduction of the config variable is a non-event if you already\n>> use the portable . notation.\n>\n> I think you got this part wrong. Until now, there was no \"portability\" to\n> worry about when using \"git add -u\". \"git add -u\" used to be _guaranteed_\n> to be relative to the cwd, with or without \".\". Our update will _break_\n> that expectation and suddenly make \".\" \"the portable notation\".\n>\n> In other words, it is far from a non-event.\n\nThere is a \"if\" in my sentence, and I do claim that if you verify the\ncondition behind the \"if\", it is a non-event.\n\nI did not claim that the whole change was a non-event, just that the\nintroduction of a config variable was.\n\n> We still have to say \"We are sorry, we will be breaking your scripts.\n> Please add an extra dot at the end\".\n\nAbsolutely. My claim is just that adding the extra dot is the way to fix\nscript wrt the future change, or at least a better way than relying on a\nconfig variable.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"}]}