{"thread":{"id":"33500","subject":"[PATCH v2 0/3] Introduce pull.autostash","startedAt":"2013-04-13T21:15:26Z","lastAt":"2013-04-16T20:53:14Z","messageCount":44,"participants":["Ramkumar Ramachandra","Philip Oakley","Junio C Hamano","Matthieu Moy","John Keeping","Jonathan Nieder","Phil Hord"],"isPatch":true,"patchVersion":2,"patchTotal":3},"messages":[{"id":"214141","messageId":"1365887729-9630-1-git-send-email-artagnon@gmail.com","threadId":"33500","inReplyTo":null,"subject":"[PATCH v2 0/3] Introduce pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-13T21:15:26Z","receivedAt":"2013-04-13T21:15:26Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"I've been using this patch for some time now, and have to say that\n'git pull' is much more useable now.  The feature is turned off by\ndefault so that it doesn't break any existing tests.\n\n[1/3] and [2/3] are simple \"while we're there\" patches, that are\nunchanged from the last round.\n\n[3/3] is actually fine in this round.  I'm embarassed that I sent out\nthe previous round in such a hurry: there were a lot of things wrong\nwith it, as Junio's review pointed out.\n\nRamkumar Ramachandra (3):\n  pull: prefer invoking \"git <command>\" over \"git-<command>\"\n  t5521 (pull-options): use test_commit() where appropriate\n  pull: introduce --[no-]autostash and pull.autostash\n\n Documentation/config.txt   |  5 ++++\n Documentation/git-pull.txt |  7 +++++\n git-pull.sh                | 37 ++++++++++++++++++++++---\n t/t5521-pull-options.sh    | 67 ++++++++++++++++++++++++++++++++++++++++++++--\n 4 files changed, 110 insertions(+), 6 deletions(-)\n\n-- \n1.8.2.1.392.g6943ea6\n"},{"id":"214142","messageId":"1365887729-9630-2-git-send-email-artagnon@gmail.com","threadId":"33500","inReplyTo":"1365887729-9630-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 1/3] pull: prefer invoking \"git <command>\" over \"git-<command>\"","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-13T21:15:27Z","receivedAt":"2013-04-13T21:15:27Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"14e5d40c (pull: Fix parsing of -X<option>, 2010-01-17) added the lines\ncontaining \"git-push\" and \"git-merge\", even though the prevelant style\nat the time was to use the unhyphenated \"git <command>\" form.  Fix\nthis.\n\nSigned-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n---\n git-pull.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 638aabb..5fe69fa 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -285,11 +285,11 @@ fi\n merge_name=$(git fmt-merge-msg $log_arg <\"$GIT_DIR/FETCH_HEAD\") || exit\n case \"$rebase\" in\n true)\n-\teval=\"git-rebase $diffstat $strategy_args $merge_args $verbosity\"\n+\teval=\"git rebase $diffstat $strategy_args $merge_args $verbosity\"\n \teval=\"$eval --onto $merge_head ${oldremoteref:-$merge_head}\"\n \t;;\n *)\n-\teval=\"git-merge $diffstat $no_commit $verify_signatures $edit $squash $no_ff $ff_only\"\n+\teval=\"git merge $diffstat $no_commit $verify_signatures $edit $squash $no_ff $ff_only\"\n \teval=\"$eval  $log_arg $strategy_args $merge_args $verbosity $progress\"\n \teval=\"$eval \\\"\\$merge_name\\\" HEAD $merge_head\"\n \t;;\n-- \n1.8.2.1.392.g6943ea6\n"},{"id":"214144","messageId":"1365887729-9630-3-git-send-email-artagnon@gmail.com","threadId":"33500","inReplyTo":"1365887729-9630-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 2/3] t5521 (pull-options): use test_commit() where appropriate","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-13T21:15:28Z","receivedAt":"2013-04-13T21:15:28Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"test_commit() is a well-defined function in test-lib-functions.sh that\nallows you to create commits with a terse syntax.  Prefer using it\nover creating commits by hand.\n\nSigned-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n---\n t/t5521-pull-options.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh\nindex aa31abe..3bdfe82 100755\n--- a/t/t5521-pull-options.sh\n+++ b/t/t5521-pull-options.sh\n@@ -7,8 +7,8 @@ test_description='pull options'\n test_expect_success 'setup' '\n \tmkdir parent &&\n \t(cd parent && git init &&\n-\t echo one >file && git add file &&\n-\t git commit -m one)\n+\t test_commit \"one\" file \"one\"\n+\t)\n '\n \n test_expect_success 'git pull -q' '\n-- \n1.8.2.1.392.g6943ea6\n"},{"id":"214143","messageId":"1365887729-9630-4-git-send-email-artagnon@gmail.com","threadId":"33500","inReplyTo":"1365887729-9630-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-13T21:15:29Z","receivedAt":"2013-04-13T21:15:29Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Currently, executing a 'git pull' on a dirty worktree gives the\nfollowing annoying message:\n\n    # User doesn't notice dirty worktree\n    $ git pull\n\n    ... # fetch operation\n\n    error: Your local changes to the following files would be overwritten by merge:\n        quux\n    Please, commit your changes or stash them before you can merge.\n    Aborting\n\nAt which point the user will stash her changes, re-execute git pull,\nand pop the stash.  This process can easily be automated out for a\nsmooth:\n\n    $ git pull\n\n    ... # fetch operation\n\n    Saved working directory and index state WIP on master: 8ea73ed baz\n    HEAD is now at 8ea73ed baz\n\n    ... # The merge/rebase process\n\n    Dropped refs/stash@{0} (83f47fbfb07a741817633f9191dc4a1530f79249)\n\nIf there is a conflict during the merge/rebase process, the user has\nto pop the stash by hand after committing the conflict resolution:\n\n    $ git pull\n\n    ... # fetch operation\n\n    Saved working directory and index state WIP on master: 8ea73ed baz\n    HEAD is now at 8ea73ed baz\n\n    ... # The merge/rebase process\n\n    Automatic merge failed; fix conflicts and then commit the result.\n    Please run 'git stash pop' after commiting the conflict resolution.\n\nIntroduce a new configuration variable pull.autostash that does\nexactly this.\n\nSigned-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n---\n Documentation/config.txt   |  5 ++++\n Documentation/git-pull.txt |  7 ++++++\n git-pull.sh                | 33 ++++++++++++++++++++++--\n t/t5521-pull-options.sh    | 63 ++++++++++++++++++++++++++++++++++++++++++++++\n 4 files changed, 106 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 3d750e0..6c5cd8e 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1804,6 +1804,11 @@ pull.rebase::\n it unless you understand the implications (see linkgit:git-rebase[1]\n for details).\n \n+pull.autostash::\n+\tWhen true, automatically stash all changes before attempting\n+\tto merge/rebase, and pop the stash after a successful\n+\tmerge/rebase.\n+\n pull.octopus::\n \tThe default merge strategy to use when pulling multiple branches\n \tat once.\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex 24ab07a..1c5384b 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -94,6 +94,13 @@ must be given before the options meant for 'git fetch'.\n \thas to be called afterwards to bring the work tree up to date with the\n \tmerge result.\n \n+--[no-]autostash::\n+\tWhen turned on, automatically stash all changes before\n+\tattempting to merge/rebase, and pop the stash after a\n+\tsuccessful merge/rebase.  Useful for people who want to pull\n+\twith a dirty worktree.  This option can also be set via the\n+\t`pull.autostash` configuration variable.\n+\n Options related to merging\n ~~~~~~~~~~~~~~~~~~~~~~~~~~\n \ndiff --git a/git-pull.sh b/git-pull.sh\nindex 5fe69fa..4edc06a 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -48,6 +48,7 @@ if test -z \"$rebase\"\n then\n \trebase=$(git config --bool pull.rebase)\n fi\n+autostash=$(git config --bool pull.autostash || echo false)\n dry_run=\n while :\n do\n@@ -116,6 +117,12 @@ do\n \t--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)\n \t\trebase=false\n \t\t;;\n+\t--autostash)\n+\t\tautostash=true\n+\t\t;;\n+\t--no-autostash)\n+\t\tautostash=false\n+\t\t;;\n \t--recurse-submodules)\n \t\trecurse_submodules=--recurse-submodules\n \t\t;;\n@@ -202,7 +209,8 @@ test true = \"$rebase\" && {\n \t\tthen\n \t\t\tdie \"$(gettext \"updating an unborn branch with changes added to the index\")\"\n \t\tfi\n-\telse\n+\telif test \"$autostash\" = false\n+\tthen\n \t\trequire_clean_work_tree \"pull with rebase\" \"Please commit or stash them.\"\n \tfi\n \toldremoteref= &&\n@@ -219,6 +227,12 @@ test true = \"$rebase\" && {\n \t\tfi\n \tdone\n }\n+\n+stash_required () {\n+\t! (git diff-files --quiet --ignore-submodules &&\n+\tgit diff-index --quiet --cached HEAD --ignore-submodules)\n+}\n+\n orig_head=$(git rev-parse -q --verify HEAD)\n git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok \"$@\" || exit 1\n test -z \"$dry_run\" || exit 0\n@@ -294,4 +308,19 @@ true)\n \teval=\"$eval \\\"\\$merge_name\\\" HEAD $merge_head\"\n \t;;\n esac\n-eval \"exec $eval\"\n+\n+if test \"$autostash\" = true && stash_required\n+then\n+\tgit stash || die \"$(gettext \"Cannot autostash\")\" &&\n+\trequire_clean_work_tree \"pull\" \"Please commit or stash them.\" &&\n+\tif eval \"$eval\"\n+\tthen\n+\t\tgit stash pop || die \"$(gettext \"Cannot pop stash\")\"\n+\telse\n+\t\texit_code=$?\n+\t\techo \"Please run 'git stash pop' after commiting the conflict resolution.\"\n+\t\texit $exit_code\n+\tfi\n+else\n+\teval \"exec $eval\"\n+fi\ndiff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh\nindex 3bdfe82..4545671 100755\n--- a/t/t5521-pull-options.sh\n+++ b/t/t5521-pull-options.sh\n@@ -117,4 +117,67 @@ test_expect_success 'git pull --all' '\n \t)\n '\n \n+test_expect_success 'pull --autostash with clean worktree' '\n+\tmkdir clonedautostash &&\n+\t(\n+\t\tcd clonedautostash &&\n+\t\tgit init &&\n+\t\tgit pull --autostash ../parent &&\n+\t\ttest_must_fail test_path_is_file .git/refs/stash\n+\t\ttest_commit one\n+\t) &&\n+\trm -rf clonedautostash\n+'\n+\n+test_expect_success 'pull.autostash with clean worktree' '\n+\tmkdir clonedautostash &&\n+\t(\n+\t\tcd clonedautostash &&\n+\t\tgit init &&\n+\t\ttest_config pull.autostash true &&\n+\t\tgit pull ../parent &&\n+\t\ttest_must_fail test_path_is_file .git/refs/stash\n+\t\ttest_commit one\n+\t) &&\n+\trm -rf clonedautostash\n+'\n+\n+test_expect_success 'pull.autostash without conflict' '\n+\tmkdir clonedautostash &&\n+\t(\n+\t\tcd clonedautostash &&\n+\t\tgit init &&\n+\t\ttest_commit \"root_commit\" &&\n+\t\tcat >quux <<-\\EOF &&\n+\t\tthis is a non-conflicting file\n+\t\tEOF\n+\t\tgit add quux &&\n+\t\ttest_config pull.autostash true &&\n+\t\tgit pull ../parent &&\n+\t\ttest_must_fail test_path_is_file .git/refs/stash &&\n+\t\ttest_path_is_file quux &&\n+\t\ttest_commit one\n+\t) &&\n+\trm -rf clonedautostash\n+'\n+\n+test_expect_success 'pull.autostash with conflict' '\n+\tmkdir clonedautostash &&\n+\t(\n+\t\tcd clonedautostash &&\n+\t\tgit init &&\n+\t\ttest_commit \"will_conflict\" file \"this is a conflicting file\" &&\n+\t\tcat >quux <<-\\EOF &&\n+\t\tthis is a non-conflicting file\n+\t\tEOF\n+\t\tgit add quux &&\n+\t\ttest_config pull.autostash true &&\n+\t\ttest_must_fail git pull ../parent &&\n+\t\ttest_must_fail test_commit one &&\n+\t\ttest_path_is_file .git/refs/stash &&\n+\t\ttest_must_fail test_path_is_file quux\n+\t) &&\n+\trm -rf clonedautostash\n+'\n+\n test_done\n-- \n1.8.2.1.392.g6943ea6\n"},{"id":"214161","messageId":"395BBE63591C415D9C8599D1A17B3892@PhilipOakley","threadId":"33500","inReplyTo":"1365887729-9630-2-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 1/3] pull: prefer invoking \"git <command>\" over \"git-<command>\"","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-04-14T09:09:17Z","receivedAt":"2013-04-14T09:09:17Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Ramkumar Ramachandra\" <artagnon@gmail.com>\nSent: Saturday, April 13, 2013 10:15 PM\n> 14e5d40c (pull: Fix parsing of -X<option>, 2010-01-17) added the lines\n> containing \"git-push\" and \"git-merge\", even though the prevelant style\n\ns /git-push/git rebase/    The fix is to a git-rebase not git-push \ninvocation.\n\n> at the time was to use the unhyphenated \"git <command>\" form.  Fix\n> this.\n>\n> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n> ---\n> git-pull.sh | 4 ++--\n> 1 file changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/git-pull.sh b/git-pull.sh\n> index 638aabb..5fe69fa 100755\n> --- a/git-pull.sh\n> +++ b/git-pull.sh\n> @@ -285,11 +285,11 @@ fi\n> merge_name=$(git fmt-merge-msg $log_arg <\"$GIT_DIR/FETCH_HEAD\") || \n> exit\n> case \"$rebase\" in\n> true)\n> - eval=\"git-rebase $diffstat $strategy_args $merge_args $verbosity\"\n> + eval=\"git rebase $diffstat $strategy_args $merge_args $verbosity\"\n>  eval=\"$eval --onto $merge_head ${oldremoteref:-$merge_head}\"\n>  ;;\n> *)\n> - eval=\"git-merge $diffstat $no_commit $verify_signatures $edit \n> $squash $no_ff $ff_only\"\n> + eval=\"git merge $diffstat $no_commit $verify_signatures $edit \n> $squash $no_ff $ff_only\"\n>  eval=\"$eval  $log_arg $strategy_args $merge_args $verbosity \n> $progress\"\n>  eval=\"$eval \\\"\\$merge_name\\\" HEAD $merge_head\"\n>  ;;\n> -- \n> 1.8.2.1.392.g6943ea6\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n>\n> -----\n> No virus found in this message.\n> Checked by AVG - www.avg.com\n> Version: 2013.0.3272 / Virus Database: 3162/6242 - Release Date: \n> 04/13/13\n> \n"},{"id":"214265","messageId":"7v8v4k2vm0.fsf@alter.siamese.dyndns.org","threadId":"33500","inReplyTo":"1365887729-9630-4-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T05:47:35Z","receivedAt":"2013-04-15T05:47:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Currently, executing a 'git pull' on a dirty worktree gives the\n> following annoying message:\n\ns/annoying//;\n\nIn general, avoid forcing your value judgement to readers when you\ndo not have to.  Instead, you can just highlight the source of your\nannoyance and let them naturally feel the annoyance themselves,\nperhaps like this:\n\n\tWhen the user runs \"git pull\" with local changes in the\n\tworking tree that interfere with the merge (or any change if\n\tthe user is using --rebase), the user is told that the merge\n\tor rebase cannot be done _after_ the command spends time to\n\tdownload necessary objects.\n\n\tThe user can then decide not to perform the pull and finish\n\twhat he was in the middle of doing (e.g. by \"git checkout -b\n\ttopic\" and then finishing the work), before coming back to\n\tthe branch and running \"git pull\" again, or \"git stash\" the\n\twork in progress, run \"git pull\" and then \"git stash pop\".\n\n\tIntroduce a new flag \"git pull --autostash\" to perform the\n\tlatter automatically. Also add pull.autostash configuration\n\tto do so without giving the command line flag, whose effect\n\tcan be overriden by the --no-autostash option.\n\nWhile I understand where this wish comes from, I am not sure if this\nis generally a good idea, or if we are solving a wrong problem.\n\n>     Saved working directory and index state WIP on master: 8ea73ed baz\n>     HEAD is now at 8ea73ed baz\n>\n>     ... # The merge/rebase process\n\nI think there is one step missing after \"The merge/rebase process\"\nabove, which is\n\n      ... # The 'stash pop' process\n\n>     Dropped refs/stash@{0} (83f47fbfb07a741817633f9191dc4a1530f79249)\n\nIf the pull-merge were something that would induce the \"annoyance\"\nthat triggered this topic, by definition, the local change overlaps\nwith the merge, and this internal \"stash pop\" will touch the paths\nthe merge touched and it is likely not result in \"Dropped\" but leave\nfurther conflicts to be resolved.\n\nIn the end, simple cases (the canonical example being Linus keeping\na local change to \"Name = Unicycling Gorilla\" in his Makefile while\nrunning dozens of \"git pull\" every day) would not be helped with\nthis feature very much because there is rarely overlap, while in a\ncomplex case the user really needs help to save away his WIP, the\nuser is forced to resolve the conflict immediately upon the failed\n\"stash pop\" at the end of \"git pull\".  If the conflict turns out to\nbe something the user would not want to resolve at that moment, the\nuser needs to know the way out, something like:\n\n\tgit reset --hard\t\t;# go back to the result of pull\n        git checkout -b wip ORIG_HEAD\t;# start from before the pull\n        git stash pop\t\t\t;# recover his wip\n\t... perhaps work a bit more ...\n        git commit -a -m wip\t\t;# save it away for safety\n\tgit checkout -\t\t\t;# result of pull\n\nso that he can come back tomorrow, check out \"wip\" branch, and\ndecide what to do.\n\n\nThe \"--autosquash\" option (or not adding either the configuration or\nthe option) would encourage the user to think about the nature of\nWIP he has in the working tree before running \"git pull\".  Is it a\ntoo complex beast that may interfere with what others are doing, or\nis it a trivial change that he can stash away and pop it back?  If\nthe former, he will be far better off doing \"checkout -b\", keep\nworking until the local change gets into somewhat a better shape and\n\"commit\", before pulling into the original branch.  If the latter,\nhe is better off doing either\n\n - \"git pull\", after finding it conflicts, run \"git stash\", \"git\n   merge FETCH_HEAD\" and \"git stash pop\"; or\n\n - \"git pull --autostash\".\n\nAnd not having \"--autostash\" would mean he would do the former, and\nwill do \"stash\" only when it matters.  \"--autostash\" is a good to\nneutral addition in that sense.  But I suspect that pull.autostash\nconfiguration is not a good addition because it encourages a bad,\npain-inducing workflow.  In simple cases it may not hurt, but when\nlocal changes are complex, it would actively hurt than not having it,\nand the configuration robs the incentive to choose.\n\nThe equation is somewhat different for \"pull-rebase\", as \"rebase\"\ninsists you to start from a clean working tree, so \"download and\nthen stop\" annoyance feels bigger.  I have a suspicion that\nloosening that may be a more productive fix to the real problem.\n\n> +stash_required () {\n> +\t! (git diff-files --quiet --ignore-submodules &&\n> +\tgit diff-index --quiet --cached HEAD --ignore-submodules)\n> +}\n\nrequire_clean_work_tree refreshes the index before running\ndiff-files to make this check safe, but you do not do that here.  Do\nyou know the index has been refreshed when this is called?\n\nEven though this is mere two-line logic, the duplication of the\nlogic look a bit wasteful.  Is it too hard to teach \"dry-run, quiet\"\nmode to require_clean_work_tree helper?  Then the auto-stash\ncodepath can simply be:\n\n\t(require_clean_work_tree --quiet) || git stash\n\nno?\n\n> +if test \"$autostash\" = true && stash_required\n> +then\n> +\tgit stash || die \"$(gettext \"Cannot autostash\")\" &&\n> +\trequire_clean_work_tree \"pull\" \"Please commit or stash them.\" &&\n> +\tif eval \"$eval\"\n> +\tthen\n> +\t\tgit stash pop || die \"$(gettext \"Cannot pop stash\")\"\n\nThis \"cannot pop stash\" is really where the user gets in the deep\nyoghurt and needs help.\n\n> +\telse\n> +\t\texit_code=$?\n> +\t\techo \"Please run 'git stash pop' after commiting the conflict resolution.\"\n\nGiven that many people do not read messages carefully, it would be a\nbetter idea to list them in the order the user carries them out,\nperhaps\n\n\tPlease resolve conflicts and commit, and then 'git stash pop'.\n\nor something.\n"},{"id":"214273","messageId":"vpq38us2oov.fsf@grenoble-inp.fr","threadId":"33500","inReplyTo":"1365887729-9630-4-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-15T08:17:04Z","receivedAt":"2013-04-15T08:17:04Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> +stash_required () {\n> +\t! (git diff-files --quiet --ignore-submodules &&\n> +\tgit diff-index --quiet --cached HEAD --ignore-submodules)\n> +}\n\nIsn't this too pessimistic? If the local changes do not overlap (in\nterms of files) with the pulled changes, then autosquash is not needed.\n\nThere should be a test for the case of non-overlapping changes.\n\n> +if test \"$autostash\" = true && stash_required\n> +then\n> +\tgit stash || die \"$(gettext \"Cannot autostash\")\" &&\n> +\trequire_clean_work_tree \"pull\" \"Please commit or stash them.\" &&\n> +\tif eval \"$eval\"\n> +\tthen\n> +\t\tgit stash pop || die \"$(gettext \"Cannot pop stash\")\"\n> +\telse\n> +\t\texit_code=$?\n> +\t\techo \"Please run 'git stash pop' after commiting the conflict resolution.\"\n> +\t\texit $exit_code\n> +\tfi\n> +else\n> +\teval \"exec $eval\"\n> +fi\n\nShouldn't this belong to \"git merge\" instead (i.e. implement \"git merge\n--autosquash\" and call it from \"git pull\")? Users doing \"git fetch &&\ngit merge\" by hand should be able to use --autosquash, I think.\n\nSomething should be done for \"git rebase\" and \"git pull --rebase\" too.\nIn this case, the UI can be much smoother, since the user would have to\nrun \"git rebase --continue\" anyway, so you can do the auto-stash-pop for\nhim by adding something like \"exec git stash pop\" at the end of the todo-list.\n\nIdeally, \"git rebase --abort\" should auto-stash-pop too, although this\nis much less trivial to implement.\n\nMaybe a good first step is to implement --autosquash only for non-rebase\npull, and later to implement \"git rebase --autosquash\" and call it from\n\"git pull\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214288","messageId":"7vbo9g15po.fsf@alter.siamese.dyndns.org","threadId":"33500","inReplyTo":"vpq38us2oov.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T09:52:19Z","receivedAt":"2013-04-15T09:52:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n>\n>> +stash_required () {\n>> +\t! (git diff-files --quiet --ignore-submodules &&\n>> +\tgit diff-index --quiet --cached HEAD --ignore-submodules)\n>> +}\n>\n> Isn't this too pessimistic? If the local changes do not overlap (in\n> terms of files) with the pulled changes, then autosquash is not needed.\n\nYes, that is why I said for pull-merge, --authsquash is neutral-to-better\nand pull.autosquash is harmful.\n\nBut for pull-rebase folks, I can understand why this \"working tree\nmust be squeakily clean\" logic is appropriate, if we were to do\nthis. The root cause is because rebase insists to be run on such a\nworking tree.\n\nAnd the worst part is that in order to check if local changes\noverlap, you need to fetch first. But Ram's annoyance is about the\nuser being told the merge/rebase cannot proceed _after_ fetch is\ndone.\n\n> Shouldn't this belong to \"git merge\" instead (i.e. implement \"git merge\n> --autosquash\" and call it from \"git pull\")? Users doing \"git fetch &&\n> git merge\" by hand should be able to use --autosquash, I think.\n\nSee my other message. I do not think autosquash would help \"merge\"\nfolks very much, and will actively hurt when it matters.\n\n> Something should be done for \"git rebase\" and \"git pull --rebase\" too.\n\nThat I would agree. I am not sure autosquash is the best approach,\nbut we should be able to help them more.\n"},{"id":"214293","messageId":"vpqbo9gqcvl.fsf@grenoble-inp.fr","threadId":"33500","inReplyTo":"7vbo9g15po.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-15T10:58:22Z","receivedAt":"2013-04-15T10:58:22Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Yes, that is why I said for pull-merge, --authsquash is neutral-to-better\n> and pull.autosquash is harmful.\n\nTo speak from my experience: I find myself typing \"git stash && git pull\n&& git stash pop\" relatively often. Typical use-case: I start working on\nsomething, a colleague works on the same thing and I need to see what he\ndid to continue. Probably not something so frequent for large projects,\nbut very frequent for small projects (e.g. writing a paper together with\na single .tex file and the deadline approaching). In this case, \"git\npull --rebase\" makes sense for advanced enough users, but newbies who\nhave been told \"rebase is too dangerous for you, don't use it\", it would\nbe cool to have --autostash too.\n\nI tend to agree that pull.autostash is harmful. At least in its current\nform, it is really too easy to overlook the \"Please run 'git stash pop'\nafter commiting the conflict resolution.\" message:\n\n<do some important changes>\n$ git pull\n<fix conflicts>\n$ git status\n<tells me to commit>\n$ git commit\n<WTF, where are my important changes?!?>\n\nrebase wouldn't have this issue if \"stash pop\" is part of the sequence\nto apply.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214298","messageId":"CALkWK0mmrvYSjvUCvvjbnav4JmbkVKho2K6c7QAM2AuqWFkEFw@mail.gmail.com","threadId":"33500","inReplyTo":"7v8v4k2vm0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T12:31:29Z","receivedAt":"2013-04-15T12:31:29Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> In the end, simple cases (the canonical example being Linus keeping\n> a local change to \"Name = Unicycling Gorilla\" in his Makefile while\n> running dozens of \"git pull\" every day) would not be helped with\n> this feature very much because there is rarely overlap, while in a\n> complex case the user really needs help to save away his WIP, the\n> user is forced to resolve the conflict immediately upon the failed\n> \"stash pop\" at the end of \"git pull\".  If the conflict turns out to\n> be something the user would not want to resolve at that moment, the\n> user needs to know the way out, something like:\n>\n>         git reset --hard                ;# go back to the result of pull\n>         git checkout -b wip ORIG_HEAD   ;# start from before the pull\n>         git stash pop                   ;# recover his wip\n>         ... perhaps work a bit more ...\n>         git commit -a -m wip            ;# save it away for safety\n>         git checkout -                  ;# result of pull\n>\n> so that he can come back tomorrow, check out \"wip\" branch, and\n> decide what to do.\n\nWhat does this have to do with pull at all?  git-pull.sh is a simple\nshell script that runs fetch followed by a merge or rebase.  You're\nhandling a merge now, and there's proper support for it in the tool;\ngit merge --abort will work with one caveat:  \"If there were\nuncommitted worktree changes present when the merge started, git merge\n--abort will in some cases be unable to reconstruct these changes. It\nis therefore recommended to always commit or stash your changes before\nrunning git merge.\", to directly quote the manpage.  Really, it has\nthe same problem as rebase, if you want --abort to work.\n\n\"Fixing\" git merge --abort and git rebase are topics for another day.\nWhat I'm doing it making it easier to work with the merge/rebase\nfollowing the fetch by automatically stashing worktree + index\nchanges.\n\n> The \"--autosquash\" option (or not adding either the configuration or\n> the option) would encourage the user to think about the nature of\n> WIP he has in the working tree before running \"git pull\".\n\nI'm lost.  What does git rebase --autosquash (or rebase.autosquash)\nhave anything to do with git pull --autostash?\n\n> Is it a\n> too complex beast that may interfere with what others are doing, or\n> is it a trivial change that he can stash away and pop it back?  If\n> the former, he will be far better off doing \"checkout -b\", keep\n> working until the local change gets into somewhat a better shape and\n> \"commit\", before pulling into the original branch.\n\nA pull-merge person having complex worktree changes should not execute\ngit pull blindly in the first place.  That's what git fetch is for:\ninspect the incoming changes, and decide how to integrate it into the\nlocal branch.  git pull is a tool that serves an entirely different\npurpose, in my opinion.\n\n> But I suspect that pull.autostash\n> configuration is not a good addition because it encourages a bad,\n> pain-inducing workflow.  In simple cases it may not hurt, but when\n> local changes are complex, it would actively hurt than not having it,\n> and the configuration robs the incentive to choose.\n\nBut I'm a pull-rebase guy, and I always want pull.autostash.  Will you\ndeny me the configuration variable, simply because it is potentially\npain-inducing to pull-merge people who set it blindly and run git pull\nblindly?\n\nI'm not arguing linking pull.autostash to pull.rebase either: my\nchange is admittedly useful to *some* pull-merge people.  And I'm not\narguing for making it true by default.\n\n> The equation is somewhat different for \"pull-rebase\", as \"rebase\"\n> insists you to start from a clean working tree, so \"download and\n> then stop\" annoyance feels bigger.  I have a suspicion that\n> loosening that may be a more productive fix to the real problem.\n\nRebase performs relatively simple operation on the worktree, and I\nwould like to keep it that way.  I have no desire to \"fix\" rebase.\n\n>         (require_clean_work_tree --quiet) || git stash\n\nGood point.  Will fix in the next iteration.\n\n> This \"cannot pop stash\" is really where the user gets in the deep\n> yoghurt and needs help.\n\nYes, and your point being?  That life would've been easier if the user\nhad committed all those changes in the first place?  And that the\npenalty for not having done that is now a git checkout wip ORIG_HEAD;\ngit stash pop; git checkout master; git rebase wip?\n\n>         Please resolve conflicts and commit, and then 'git stash pop'.\n\nCool, will fix.\n"},{"id":"214299","messageId":"CALkWK0mdC_tK2CGqAa67fr189PQCjSjzAOPujipOHFfoiYW0qA@mail.gmail.com","threadId":"33500","inReplyTo":"vpq38us2oov.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T13:15:58Z","receivedAt":"2013-04-15T13:15:58Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> Isn't this too pessimistic? If the local changes do not overlap (in\n> terms of files) with the pulled changes, then autosquash is not needed.\n>\n> There should be a test for the case of non-overlapping changes.\n\nIn the pull-rebase case, no; it is not too pessimistic.\n\nIn the pull-merge case, maybe: if your worktree isn't clean, you lose\na lot of goodies like merge --abort anyway, and I hate that.\nSecondly, it's impossible to determine whether the changes overlap or\nnot before actually running merge_trees().  If there were an easy way\nto do it, I might have considered it.\n\nOverall, I don't see how an extra stash/ stash pop where not\nabsolutely necessary hurts.\n\n> Shouldn't this belong to \"git merge\" instead (i.e. implement \"git merge\n> --autosquash\" and call it from \"git pull\")? Users doing \"git fetch &&\n> git merge\" by hand should be able to use --autosquash, I think.\n\n--autosquash reminds me of rebase.autosquash, and that is completely\nunrelated to the issue at hand.  Did you mean git merge --squash (to\nupdate the worktree/index but not create the actual commit?).  Sure,\nit's probably useful to have a merge.squash configuration variable,\nbut I don't see what it has to do with the pull.autostash I'm\nproposing.\n\n> Something should be done for \"git rebase\" and \"git pull --rebase\" too.\n> In this case, the UI can be much smoother, since the user would have to\n> run \"git rebase --continue\" anyway, so you can do the auto-stash-pop for\n> him by adding something like \"exec git stash pop\" at the end of the todo-list.\n\nNo.  I'm against executing a special codepath for a pull-rebase that\nhas no equivalent in the pull-merge world.  Or did you mean: have one\nconfiguration variable to git merge --squash and do this for git\nrebase, as if they're equivalent from the pull perspective?  No, they\naren't.\n\n> Ideally, \"git rebase --abort\" should auto-stash-pop too, although this\n> is much less trivial to implement.\n\nAs I already pointed out in my message to Junio, \"fixing\" rebase is\nnot the topic of discussion at all.\n\n> Maybe a good first step is to implement --autosquash only for non-rebase\n> pull, and later to implement \"git rebase --autosquash\" and call it from\n> \"git pull\".\n\n\"Implement\" git rebase --autosquash?  If I just set rebase.autosquash\nto true, the rebase will automatically autosquash whether called from\ngit pull or otherwise.  Sorry, I just don't understand what you're\nsaying.\n"},{"id":"214300","messageId":"CALkWK0nymT=wTnHpTE=uBsqoHxACFb4gStU0SGE79bc7uBVKXQ@mail.gmail.com","threadId":"33500","inReplyTo":"vpqbo9gqcvl.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T13:29:44Z","receivedAt":"2013-04-15T13:29:44Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> I tend to agree that pull.autostash is harmful. At least in its current\n> form, it is really too easy to overlook the \"Please run 'git stash pop'\n> after commiting the conflict resolution.\" message:\n>\n> <do some important changes>\n> $ git pull\n> <fix conflicts>\n> $ git status\n> <tells me to commit>\n> $ git commit\n> <WTF, where are my important changes?!?>\n\nFirst, this is not why Junio said pull.autostash is harmful: he had a\ncompletely different objection.\n\nSecond, this makes no sense.  The user consciously made the decision\nto set pull.autostash to true: it isn't turned on by default, and\nthere's no magic that's turning it on without the user knowing.  This\ncase is roughly equivalent to the user executing 'git stash' and\nsuddenly waking up one day and complaining \"WTF, where are my\nimportant changes?!?\".  Sure, it might be a good idea to teach git\nstatus to show the stash state, but that's an orthogonal topic.\n"},{"id":"214301","messageId":"vpqppxvoqsc.fsf@grenoble-inp.fr","threadId":"33500","inReplyTo":"CALkWK0mdC_tK2CGqAa67fr189PQCjSjzAOPujipOHFfoiYW0qA@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-15T13:40:51Z","receivedAt":"2013-04-15T13:40:51Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> In the pull-merge case, maybe: if your worktree isn't clean, you lose\n> a lot of goodies like merge --abort anyway, and I hate that.\n\nAFAICT, \"git merge --abort\" is an alias for \"git reset --merge\" which\nwas precisely designed to reset only modifications comming from a merge,\nand not the local changes that were present before the merge was\nstarted. The man pages are relatively obscure on the subject, but I'd\ncall that a documentation bug.\n\n> Overall, I don't see how an extra stash/ stash pop where not\n> absolutely necessary hurts.\n\nIt does. stashing means the user will have to \"stash pop\" later. One\nextra step, one extra opportunity to forget something important.\n\nA minor annoyance is that it will touch files that have no reason to be\ntouched, hence may trigger extra rebuilds with \"make\", disturbing text\neditors that have the file open, etc.\n\nThe fact that \"git pull\" just works on dirty trees with non-overlapping\nchanges is an important feature of Git.\n\n>> Shouldn't this belong to \"git merge\" instead (i.e. implement \"git merge\n>> --autosquash\" and call it from \"git pull\")? Users doing \"git fetch &&\n>> git merge\" by hand should be able to use --autosquash, I think.\n>\n> --autosquash reminds me of rebase.autosquash, and that is completely\n> unrelated to the issue at hand.\n\nA typo seems to have propagated in this thread. I meant auto*stash*, not\nauto*squash*, sorry. I guess it's the same typo in Junio's message.\n\n>> Something should be done for \"git rebase\" and \"git pull --rebase\" too.\n>> In this case, the UI can be much smoother, since the user would have to\n>> run \"git rebase --continue\" anyway, so you can do the auto-stash-pop for\n>> him by adding something like \"exec git stash pop\" at the end of the todo-list.\n>\n> No.  I'm against executing a special codepath for a pull-rebase that\n> has no equivalent in the pull-merge world.\n\nI think you're taking it the wrong way. You seem to insist that\nautostash should be a pull feature. I think it should be a feature of\nmerge and rebase, and the convenience script \"git pull\" should expose\nthem to the user.\n\nI see no reason to prevent users running fetch and then merge or rebase\nto use the autostash feature.\n\n>> Ideally, \"git rebase --abort\" should auto-stash-pop too, although this\n>> is much less trivial to implement.\n>\n> As I already pointed out in my message to Junio, \"fixing\" rebase is\n> not the topic of discussion at all.\n\nIt's not about fixing the existing rebase. It's about implementing\nautostash the right way.\n\nAs a user, when I run \"git rebase --continue\" and it tells me it's done,\nI expect the work to actually be done. This is the case today. This\nwon't be the case after autostash is introduced if the user has to\nremember to run \"stash pop\" afterwards.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214302","messageId":"vpqbo9foqld.fsf@grenoble-inp.fr","threadId":"33500","inReplyTo":"CALkWK0nymT=wTnHpTE=uBsqoHxACFb4gStU0SGE79bc7uBVKXQ@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-15T13:45:02Z","receivedAt":"2013-04-15T13:45:02Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> First, this is not why Junio said pull.autostash is harmful: he had a\n> completely different objection.\n\nYes. This is another objection.\n\n> Second, this makes no sense.  The user consciously made the decision\n> to set pull.autostash to true\n\n... possibly a long time ago.\n\n> This case is roughly equivalent to the user executing 'git stash' and\n> suddenly waking up one day and complaining \"WTF, where are my\n> important changes?!?\".\n\nI disagree. A configuration option is something you set once, and then\nforget about. A command, or a command-line option, is something you\nexplicitely add when you need it.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214303","messageId":"CALkWK0nqrw7DFQSnMvULYjJtBHRnadKWqCLQOAjzJH0o7USo+A@mail.gmail.com","threadId":"33500","inReplyTo":"vpqppxvoqsc.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T13:56:41Z","receivedAt":"2013-04-15T13:56:41Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> AFAICT, \"git merge --abort\" is an alias for \"git reset --merge\"\n\nYes, that is correct.\n\n> which\n> was precisely designed to reset only modifications comming from a merge,\n> and not the local changes that were present before the merge was\n> started. The man pages are relatively obscure on the subject, but I'd\n> call that a documentation bug.\n\nI see.  Either way, we need a clean worktree for it to work, no?\n\n> It does. stashing means the user will have to \"stash pop\" later. One\n> extra step, one extra opportunity to forget something important.\n\nThat's only if there are conflicts.  If there are conflicts, you'll\nhave to stash anyway if:\n- You're doing a pull-merge and want merge --abort to work.\n- You're doing a pull-rebase.\n\nIn the case when there are no conflicts, what is the problem?\n\n> A minor annoyance is that it will touch files that have no reason to be\n> touched, hence may trigger extra rebuilds with \"make\", disturbing text\n> editors that have the file open, etc.\n\nOkay, I need to ask you something at this point: do you ever run merge\non a dirty worktree unless you're absolutely sure that your local\nchanges won't conflict with the changes introduced by the merge?  I\n_never_ run merge on a dirty worktree myself.\n\n> The fact that \"git pull\" just works on dirty trees with non-overlapping\n> changes is an important feature of Git.\n\nThat's only a pull-merge.  Unfortunately, making git-pull.sh uniform\nmeans that we have to fall back to the least-common-denominator of\nfunctionality (which is currently pull-rebase).\n\n> I think you're taking it the wrong way. You seem to insist that\n> autostash should be a pull feature. I think it should be a feature of\n> merge and rebase, and the convenience script \"git pull\" should expose\n> them to the user.\n>\n> I see no reason to prevent users running fetch and then merge or rebase\n> to use the autostash feature.\n\nOkay, so you're proposing a uniform --autostash feature for both merge\nand rebase.  Sorry, I didn't get it last time due to the typos in your\nemail; yeah, this is worth investigating.\n\n> As a user, when I run \"git rebase --continue\" and it tells me it's done,\n> I expect the work to actually be done. This is the case today. This\n> won't be the case after autostash is introduced if the user has to\n> remember to run \"stash pop\" afterwards.\n\nAnd how will you implement that for merge, since there is no merge\n--continue to execute stash pop from?  Do you propose to make commit\ndo the stash pop'ing?\n"},{"id":"214305","messageId":"CALkWK0mLxZCr-QK2tkR9xEsocj6GAM7FZOSeiJ9SnEusfnv88g@mail.gmail.com","threadId":"33500","inReplyTo":"vpqbo9foqld.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T14:31:46Z","receivedAt":"2013-04-15T14:31:46Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> I disagree. A configuration option is something you set once, and then\n> forget about. A command, or a command-line option, is something you\n> explicitely add when you need it.\n\nYou're making it out to be a much bigger difference than it actually\nis.  Users will simply alias pull to 'pull --autostash' (a lot of them\nalready alias it to pull --ff-only, and I'm going to fix this soon).\nThe decision making process for creating a configuration variable\nshouldn't be \"this is potentially dangerous, and therefore therefore\nit shouldn't be a configuration variable\", but rather \"this is a\nrarely used option that users only need <50% of the time, and\ntherefore it shouldn't be a configuration variable\".  In my case,\npull.autostash is my 90~95% usecase, and I'm not unique in this\naspect.  Therefore, it should be a configuration variable that can be\nconsciously turned off with a --no-autostash.\n\nIf your criticism were that git status doesn't show stash state, I\nagree with you.  However, I don't agree with basing it on user\nforgetfulness in having set pull.autostash a long time ago + lack of\nobservation skills to notice the message printed by git pull.\n"},{"id":"214308","messageId":"CALkWK0kUoW22d67Ufc0i2OTVuRC8G6xGiR4Joz9vLh_4+bkuZQ@mail.gmail.com","threadId":"33500","inReplyTo":"CALkWK0nqrw7DFQSnMvULYjJtBHRnadKWqCLQOAjzJH0o7USo+A@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T15:04:04Z","receivedAt":"2013-04-15T15:04:04Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Okay, so you're proposing a uniform --autostash feature for both merge\n> and rebase.  Sorry, I didn't get it last time due to the typos in your\n> email; yeah, this is worth investigating.\n\nSo, I thought about this and have concluded that pull is the Right\nplace for autostash because of the following reasons:\n\n0. autostash is purely a convenience function that's useful in simple\nreduced cases like a dumb 'git pull'; when the script we're\nimplementing it for doesn't have a ton of command-line options.\n\n1. git stash; git pull; git stash pop; is a very common idiom.  git\nstash; git rebase master; git stash pop; is a less common idiom, but I\nagree that it is one rebase case where autostash could be useful.\nHaving git rebase -i show \"exec git stash pop\" at the end of a\nuser-editable instruction sheet is less than ideal.  Having git rebase\n--onto master HEAD~3 do an autostash _might_ be useful, but I'm not\nsure about it.  git stash; git merge feature-branch; git stash pop; is\nnot a common idiom at all.\n\n2. git-stash.sh is a helper script, in the same spirit as git-pull.sh\nand git-rebase.sh.  It is natural and easy to implement autostash for\npull and rebase, but not for a C builtin like merge.  In fact, it's\nimpossible to implement it for merge unless we make git commit execute\ngit stash pop (yuck!).\n\nIf you want, you can implement a rebase.autostash, but that is not my\nitch.  Considering the gymnastics the implementation would have to do,\nI'd be against a merge.autostash.  So, again: what is your gripe\nagainst my pull.autostash implementation, apart from the fact that git\nstatus doesn't show stash information? (I _might_ decide to fix this)\n"},{"id":"214309","messageId":"7vsj2rzuwl.fsf@alter.siamese.dyndns.org","threadId":"33500","inReplyTo":"CALkWK0mmrvYSjvUCvvjbnav4JmbkVKho2K6c7QAM2AuqWFkEFw@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T15:16:26Z","receivedAt":"2013-04-15T15:16:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> In the end, simple cases (the canonical example being Linus keeping\n>> a local change to \"Name = Unicycling Gorilla\" in his Makefile while\n>> running dozens of \"git pull\" every day) would not be helped with\n>> this feature very much because there is rarely overlap, while in a\n>> complex case the user really needs help to save away his WIP, the\n>> user is forced to resolve the conflict immediately upon the failed\n>> \"stash pop\" at the end of \"git pull\".  If the conflict turns out to\n>> be something the user would not want to resolve at that moment, the\n>> user needs to know the way out, something like:\n>>\n>>         git reset --hard                ;# go back to the result of pull\n>>         git checkout -b wip ORIG_HEAD   ;# start from before the pull\n>>         git stash pop                   ;# recover his wip\n>>         ... perhaps work a bit more ...\n>>         git commit -a -m wip            ;# save it away for safety\n>>         git checkout -                  ;# result of pull\n>>\n>> so that he can come back tomorrow, check out \"wip\" branch, and\n>> decide what to do.\n>\n> What does this have to do with pull at all?\n\nExactly.\n\nBy tempting the user to use autostash first, you are forcing the\nuser to say \"reset --hard\" (the first one), \"ORIG_HEAD\" (to start\nfrom the pre-pull state), \"stash pop\" (to recover the autostashed\nWIP), to a user who got conflict during \"stash pop\" after the pull\nintegrated the committed work with the remote side.\n\nIf the user did this instead:\n\n        ... Let's save my large WIP away in a more permanent place first\n\tgit checkout -b wip\n        ... perhaps work a bit more ...\n        git commit -a -m wip\n        git checkout -\n\t... and then ...\n\tgit pull\n\nthe user wouldn't have had to do those extra steps.\n\nAnother thing to consider is that even with the current system, many\nusers do not have a clear idea on what the state of the working tree\nis when a \"pull\" fails (there are largely two classes). Either the\nmerge failed without damaging the WIP before the pull at all, or\nthere wasn't any interaction between the WIP and the change pull\nwanted to bring in and only the paths with conflicts need to be\nresolved and added (i.e. \"commit -a\" is a no-no). This \"auto-pop\"\nadds a third failure mode to \"pull\". It is a non-issue for Git-heads\nlike us (we do read the messages from the programs), but not all\nusers are like us.\n\n>> The \"--autosquash\" option (or not adding either the configuration or\n>> the option) would encourage the user to think about the nature of\n>> WIP he has in the working tree before running \"git pull\".\n>\n> I'm lost.  What does git rebase --autosquash (or rebase.autosquash)\n> have anything to do with git pull --autostash?\n\nSorry, the typo meant --autostash.\n\n>> Is it a\n>> too complex beast that may interfere with what others are doing, or\n>> is it a trivial change that he can stash away and pop it back?  If\n>> the former, he will be far better off doing \"checkout -b\", keep\n>> working until the local change gets into somewhat a better shape and\n>> \"commit\", before pulling into the original branch.\n>\n> A pull-merge person having complex worktree changes should not execute\n> git pull blindly in the first place.   That's what git fetch is for:\n\nHuh?  You are not making sense.\n\nI would understand it if it were \"That's what git commit is for\",\nthough.\n\n> But I'm a pull-rebase guy, and I always want pull.autostash.\n\nThat is why I said the equation is different for pull-rebase, where\n\"rebase\" insists that you start from a squeaky clean working tree,\nso you can check the condition early before \"git pull\" even starts.\nWhile --autostash will not improve the life for pull-merge people\n(and pull.autostash will actively hurt them), pull.autostash does\nhelp pull-rebase people work around the limitation of \"rebase\".\n"},{"id":"214311","messageId":"7vobdfztz9.fsf@alter.siamese.dyndns.org","threadId":"33500","inReplyTo":"vpqppxvoqsc.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T15:36:26Z","receivedAt":"2013-04-15T15:36:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> I think you're taking it the wrong way. You seem to insist that\n> autostash should be a pull feature. I think it should be a feature of\n> merge and rebase, and the convenience script \"git pull\" should expose\n> them to the user.\n>\n> I see no reason to prevent users running fetch and then merge or rebase\n> to use the autostash feature.\n\nI agree that is a good way to look at the problem and would lead to\na much better design of the division of labor among these three\nmoving parts.\n\n> It's not about fixing the existing rebase. It's about implementing\n> autostash the right way.\n>\n> As a user, when I run \"git rebase --continue\" and it tells me it's done,\n> I expect the work to actually be done. This is the case today. This\n> won't be the case after autostash is introduced if the user has to\n> remember to run \"stash pop\" afterwards.\n\nYour \"rebase can do the autostash right way\" idea in the other\nmessage is a good one, I think.  The rebase proper will sequencially\neither apply patches (if the user is using the \"format-patch | am\"\nvariant) or cherry-pick commits (\"rebase -m\").  Conceptually we can\nview the WIP in the working tree as just another commit at the tip\nof the original history to be rebased (modulo that it should not be\nleft as a commit in the resulting history, and we may need to\ndifferentiate what was in the index and what was only in the working\ntree).  Ignoring the \"conflicts at stash pop time\" issue for now, a\nrough outline may look like:\n\n\tgit-rebase --autostash\n\n\t\tgit commit --allow-empty -m 'index part'\n\t        git commit --allow-empty -a -m 'working tree part'\n                git rebase --onto $UPSTREAM\n                git reset HEAD^\n                git reset --soft HEAD^\n\nThe first \"reset\" is to match the index to what was \"stashed\" with\nthe first \"commit\" ('index part') while keeping the working tree\nchanges the original WIP had ('working tree part'), and the last\n\"reset --soft\" is to move the HEAD back to the tip of the originally\ncommitted history.\n"},{"id":"214315","messageId":"vpqwqs3lqlf.fsf@grenoble-inp.fr","threadId":"33500","inReplyTo":"CALkWK0nqrw7DFQSnMvULYjJtBHRnadKWqCLQOAjzJH0o7USo+A@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-15T16:13:16Z","receivedAt":"2013-04-15T16:13:16Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Matthieu Moy wrote:\n>> AFAICT, \"git merge --abort\" is an alias for \"git reset --merge\"\n>\n> Yes, that is correct.\n>\n>> which\n>> was precisely designed to reset only modifications comming from a merge,\n>> and not the local changes that were present before the merge was\n>> started. The man pages are relatively obscure on the subject, but I'd\n>> call that a documentation bug.\n>\n> I see.  Either way, we need a clean worktree for it to work, no?\n\nNo, you don't. Just try if you're not convinced:\n\n$ git checkout -b branch\nSwitched to a new branch 'branch'\n$ date > test.txt && git commit -m 'on branch' test.txt\n[branch 2482623] on branch\n 1 file changed, 1 insertion(+), 1 deletion(-)\n$ git checkout -\nSwitched to branch 'master'\n$ date > test.txt && git commit -m 'on master' test.txt\n[master c322d35] on master\n 1 file changed, 1 insertion(+), 1 deletion(-)\n$ date > other.txt \n$ git status\n# On branch master\n# Changes not staged for commit:\n#\n#       modified:   other.txt\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git merge branch\nAuto-merging test.txt\nCONFLICT (content): Merge conflict in test.txt\nAutomatic merge failed; fix conflicts and then commit the result.\n$ git status\n# On branch master\n# You have unmerged paths.\n#\n# Unmerged paths:\n#\n#       both modified:      test.txt\n#\n# Changes not staged for commit:\n#\n#       modified:   other.txt\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git merge --abort\n$ git status\n# On branch master\n# Changes not staged for commit:\n#\n#       modified:   other.txt\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ \n\nThere may be corner-cases where it doesn't work, but I never encountered\nsuch case.\n\n>> It does. stashing means the user will have to \"stash pop\" later. One\n>> extra step, one extra opportunity to forget something important.\n>\n> That's only if there are conflicts.  If there are conflicts, you'll\n> have to stash anyway if:\n> - You're doing a pull-merge and want merge --abort to work.\n\nAgain, no.\n\n>> A minor annoyance is that it will touch files that have no reason to be\n>> touched, hence may trigger extra rebuilds with \"make\", disturbing text\n>> editors that have the file open, etc.\n>\n> Okay, I need to ask you something at this point: do you ever run merge\n> on a dirty worktree unless you're absolutely sure that your local\n> changes won't conflict with the changes introduced by the merge? \n\nMost of the time, I just run \"git pull\" or \"git merge\". I know it's\nconservative enough, to it will stop if there's anything dangerous.\n\n> That's only a pull-merge.  Unfortunately, making git-pull.sh uniform\n> means that we have to fall back to the least-common-denominator of\n> functionality (which is currently pull-rebase).\n\nYou may want to, but you don't have to. pull-merge and pull-rebase\nalready have different behavior in case of non-overlapping changes:\n\n$ git pull --rebase . branch\nCannot pull with rebase: You have unstaged changes.\nPlease commit or stash them.\n$ git pull --no-rebase . branch\nFrom .\n * branch            branch     -> FETCH_HEAD\n[...]\n\nI don't see any reason to restrict to the common denominator in the same\nsituation for another feature.\n\nI can accept the \"it's too hard to implement\" argument, but not \"it\ndoesn't bring anything\".\n\n>> As a user, when I run \"git rebase --continue\" and it tells me it's done,\n>> I expect the work to actually be done. This is the case today. This\n>> won't be the case after autostash is introduced if the user has to\n>> remember to run \"stash pop\" afterwards.\n>\n> And how will you implement that for merge, since there is no merge\n> --continue to execute stash pop from?  Do you propose to make commit\n> do the stash pop'ing?\n\nNo, I'm not proposing to do anything for merge. There's no reason to try\nbeing uniform in conflict resolution for pull-merge and pull-rebase as\nit is already different now. We already have \"git rebase --continue\", we\ndon't have \"git merge --continue\". So what? The fact that merge doesn't\nhave the equivalent doesn't mean we should not do something for \"rebase\n--continue\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214317","messageId":"vpqmwszlqek.fsf@grenoble-inp.fr","threadId":"33500","inReplyTo":"CALkWK0mLxZCr-QK2tkR9xEsocj6GAM7FZOSeiJ9SnEusfnv88g@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-15T16:17:23Z","receivedAt":"2013-04-15T16:17:23Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Matthieu Moy wrote:\n>> I disagree. A configuration option is something you set once, and then\n>> forget about. A command, or a command-line option, is something you\n>> explicitely add when you need it.\n>\n> You're making it out to be a much bigger difference than it actually\n> is.  Users will simply alias pull to 'pull --autostash' (a lot of them\n> already alias it to pull --ff-only, and I'm going to fix this soon).\n\nNo, they don't.  Git forbids redefining commands with aliases. They may\nhave an alias like \"git pullauto\" or so, but not \"git pull\".\n\n> If your criticism were that git status doesn't show stash state, I\n> agree with you.\n\nThere's not much we can do about it now, as Git cannot guess whether a\nstash is to be re-applied later or just kept \"in case\". My main use of\n\"git stash\" is \"I want a reset --hard, but stash is safer\", I wouldn't\nwant \"status\" to remind me when I have a stash because it is almost\nalways the case.\n\nShowing the \"autostash\" status in \"git status\" would make sense OTOH,\nbut I agree that it's another topic.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214320","messageId":"CALkWK0kMRm74SOiZ7Jgm2xqS5UEc5HOXQ6F12QqLnhO=QGktew@mail.gmail.com","threadId":"33500","inReplyTo":"7vsj2rzuwl.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T16:31:53Z","receivedAt":"2013-04-15T16:31:53Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> By tempting the user to use autostash first, you are forcing the\n> user to say \"reset --hard\" (the first one), \"ORIG_HEAD\" (to start\n> from the pre-pull state), \"stash pop\" (to recover the autostashed\n> WIP), to a user who got conflict during \"stash pop\" after the pull\n> integrated the committed work with the remote side.\n>\n> If the user did this instead:\n>\n>         ... Let's save my large WIP away in a more permanent place first\n>         git checkout -b wip\n>         ... perhaps work a bit more ...\n>         git commit -a -m wip\n>         git checkout -\n>         ... and then ...\n>         git pull\n>\n> the user wouldn't have had to do those extra steps.\n\nHm, yes.  For a pull-merge guy who opts for pull.autostash, the\npenalty for forgetting to commit a big WIP in advance is too high.  It\nprobably makes sense to restrict the autostash feature to kick in only\nin the rebase codepath: it might be a good idea to implement\nrebase.autostash for reduced case of non-interactive rebases instead.\nI'm only slightly iffy about --onto, but it's not a big concern.\n"},{"id":"214319","messageId":"7vbo9fzre8.fsf@alter.siamese.dyndns.org","threadId":"33500","inReplyTo":"vpqwqs3lqlf.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T16:32:15Z","receivedAt":"2013-04-15T16:32:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n>\n>> Matthieu Moy wrote:\n>>> AFAICT, \"git merge --abort\" is an alias for \"git reset --merge\"\n>>\n>> Yes, that is correct.\n>>\n>>> which\n>>> was precisely designed to reset only modifications comming from a merge,\n>>> and not the local changes that were present before the merge was\n>>> started. The man pages are relatively obscure on the subject, but I'd\n>>> call that a documentation bug.\n>>\n>> I see.  Either way, we need a clean worktree for it to work, no?\n>\n> No, you don't. Just try if you're not convinced:\n\nHeh, I still remember breaking \"git merge\" and got yelled at loudly.\n\ncf. http://thread.gmane.org/gmane.comp.version-control.git/9073\n\n>>> It does. stashing means the user will have to \"stash pop\" later. One\n>>> extra step, one extra opportunity to forget something important.\n>>\n>> That's only if there are conflicts.  If there are conflicts, you'll\n>> have to stash anyway if:\n>> - You're doing a pull-merge and want merge --abort to work.\n>\n> Again, no.\n>\n>>> A minor annoyance is that it will touch files that have no reason to be\n>>> touched, hence may trigger extra rebuilds with \"make\", disturbing text\n>>> editors that have the file open, etc.\n>>\n>> Okay, I need to ask you something at this point: do you ever run merge\n>> on a dirty worktree unless you're absolutely sure that your local\n>> changes won't conflict with the changes introduced by the merge? \n>\n> Most of the time, I just run \"git pull\" or \"git merge\". I know it's\n> conservative enough, to it will stop if there's anything dangerous.\n\nExactly.\n\n> No, I'm not proposing to do anything for merge. There's no reason to try\n> being uniform in conflict resolution for pull-merge and pull-rebase as\n> it is already different now. We already have \"git rebase --continue\", we\n> don't have \"git merge --continue\". So what? The fact that merge doesn't\n> have the equivalent doesn't mean we should not do something for \"rebase\n> --continue\".\n\nWell said.\n"},{"id":"214322","messageId":"CALkWK0=cNEkE0bUoWJg119o+FaQywJhgkUxiFfLGPSsLrFVZ=A@mail.gmail.com","threadId":"33500","inReplyTo":"7vobdfztz9.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T16:38:34Z","receivedAt":"2013-04-15T16:38:34Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n>         git-rebase --autostash\n>\n>                 git commit --allow-empty -m 'index part'\n>                 git commit --allow-empty -a -m 'working tree part'\n>                 git rebase --onto $UPSTREAM\n>                 git reset HEAD^\n>                 git reset --soft HEAD^\n\nWhy are you rolling your own stash?  What do you have against git stash?\n"},{"id":"214324","messageId":"CALkWK0nrVZo3MSgqpPmX2+T3JJ8uP=hzH3PMv+qd4ZaqNVwEsw@mail.gmail.com","threadId":"33500","inReplyTo":"vpqwqs3lqlf.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T16:45:54Z","receivedAt":"2013-04-15T16:45:54Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> No, you don't. Just try if you're not convinced:\n\nOh, I trusted the documentation on this one and never tried with a\ndirty worktree myself.  Please fix the documentation, if you know how\nexactly to correct it.\n\n> No, I'm not proposing to do anything for merge. There's no reason to try\n> being uniform in conflict resolution for pull-merge and pull-rebase as\n> it is already different now. We already have \"git rebase --continue\", we\n> don't have \"git merge --continue\". So what? The fact that merge doesn't\n> have the equivalent doesn't mean we should not do something for \"rebase\n> --continue\".\n\nWell, you can't blame me for the misunderstanding then.\n\nIn a previous email, you wrote:\n> Shouldn't this belong to \"git merge\" instead (i.e. implement \"git merge\n> --autosquash\" and call it from \"git pull\")? Users doing \"git fetch &&\n> git merge\" by hand should be able to use --autosquash, I think.\n\nJunio's criticism of pull.autostash hurting pull-merge people is\ncogent; my current plan is to ditch pull.autostash altogether, and\nimplement rebase.autostash for the reduced case of a non-interactive\nrebase.\n"},{"id":"214326","messageId":"CALkWK0mzv8YZS8hctun-k-CnEzWo3TbJwmFX+Z4En8UHjNd5ww@mail.gmail.com","threadId":"33500","inReplyTo":"vpqmwszlqek.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T16:52:20Z","receivedAt":"2013-04-15T16:52:20Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> No, they don't.  Git forbids redefining commands with aliases. They may\n> have an alias like \"git pullauto\" or so, but not \"git pull\".\n\nOfcourse, but you get the point.  I use p for push, and pu for pull myself.\n\n> There's not much we can do about it now, as Git cannot guess whether a\n> stash is to be re-applied later or just kept \"in case\". My main use of\n> \"git stash\" is \"I want a reset --hard, but stash is safer\", I wouldn't\n> want \"status\" to remind me when I have a stash because it is almost\n> always the case.\n>\n> Showing the \"autostash\" status in \"git status\" would make sense OTOH,\n> but I agree that it's another topic.\n\nIf the HEAD of the stash contains a stash beginning with the message\n\"pull.autostash: \", show it in the status.  End of story.\n\nAnyway, no point arguing about this since we've decided not to pursue\npull.autostash anyway.\n"},{"id":"214327","messageId":"20130415165352.GH2278@serenity.lan","threadId":"33500","inReplyTo":"CALkWK0nrVZo3MSgqpPmX2+T3JJ8uP=hzH3PMv+qd4ZaqNVwEsw@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-04-15T16:53:53Z","receivedAt":"2013-04-15T16:53:53Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, Apr 15, 2013 at 10:15:54PM +0530, Ramkumar Ramachandra wrote:\n> Junio's criticism of pull.autostash hurting pull-merge people is\n> cogent; my current plan is to ditch pull.autostash altogether, and\n> implement rebase.autostash for the reduced case of a non-interactive\n> rebase.\n\nWhy restrict it to non-interactive?  I'd find it useful when doing\ninteractive rebases as well - consider the case when you simply want to\nre-order some commits.\n"},{"id":"214328","messageId":"CALkWK0m5rnQPkJGd6mjmFP4BKCe+Cip2ifh94a9FHzYTiYtm8Q@mail.gmail.com","threadId":"33500","inReplyTo":"20130415165352.GH2278@serenity.lan","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T17:05:09Z","receivedAt":"2013-04-15T17:05:09Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"John Keeping wrote:\n> Why restrict it to non-interactive?  I'd find it useful when doing\n> interactive rebases as well - consider the case when you simply want to\n> re-order some commits.\n\nActually, I made a mistake: it should be doable for any specific\nrebase (includes rebase--interactive, rebase--am, and rebase--merge)\njust as easily, without leaking the autostash detail into them.  The\nlast statement in git-rebase.sh is run_specific_rebase, which just\nneeds to be wrapped in a git stash/ git stash pop.\n"},{"id":"214347","messageId":"7vr4ibu14j.fsf@alter.siamese.dyndns.org","threadId":"33500","inReplyTo":"CALkWK0=cNEkE0bUoWJg119o+FaQywJhgkUxiFfLGPSsLrFVZ=A@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T17:58:36Z","receivedAt":"2013-04-15T17:58:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>>         git-rebase --autostash\n>>\n>>                 git commit --allow-empty -m 'index part'\n>>                 git commit --allow-empty -a -m 'working tree part'\n>>                 git rebase --onto $UPSTREAM\n>>                 git reset HEAD^\n>>                 git reset --soft HEAD^\n>\n> Why are you rolling your own stash?  What do you have against git stash?\n\nNothing.  It just felt that it does not _have to be_ implemented\nwith stash, and explaining things in terms of commit and reset would\nbe simpler.\n\nIf \"rebase -m\" were to be taught to do this, the natural way to do\nso is to \n\n  (1) Prepare the todo the usual way\n  (2) Do those two commits for index and working tree\n  (3) Append two insns (exec reset HEAD^ and exec reset --soft\n      HEAD^) at the end of the rebase todo file.\n\nThen the usual \"rebase --continue\" would just work.  Instead you\ncould use \"git stash\" at step #2 and add \"exec git stash pop\" at\nstep #3.\n\n\"rebase--am\" could also be told to generate (on the preparation\nside) and notice (on the application side) a pair of patch files at\nthe end that represent the index state and the working tree state\nand apply them without making the WIP part into a commit.\n"},{"id":"214350","messageId":"CALkWK0=6E=s6kJysMo2yC22c3pvCWn90S5neRyP0jpzpYrZboA@mail.gmail.com","threadId":"33500","inReplyTo":"7vr4ibu14j.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T18:08:20Z","receivedAt":"2013-04-15T18:08:20Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> If \"rebase -m\" were to be taught to do this, the natural way to do\n> so is to\n>\n>   (1) Prepare the todo the usual way\n>   (2) Do those two commits for index and working tree\n>   (3) Append two insns (exec reset HEAD^ and exec reset --soft\n>       HEAD^) at the end of the rebase todo file.\n\nEr, no.  I don't want to touch the instruction sheet.  It becomes\nespecially problematic in -i, when the instruction sheet is\nuser-editable.\n\n> \"rebase--am\" could also be told to generate (on the preparation\n> side) and notice (on the application side) a pair of patch files at\n> the end that represent the index state and the working tree state\n> and apply them without making the WIP part into a commit.\n\nUgh, no.  I don't want to leak the implementation detail of autostash\ninto specific rebases.  Why can't I wrap the last statment in\ngit-rebase.sh in git stash/ git stash pop like I did with git-pull.sh?\n"},{"id":"214354","messageId":"20130415181551.GJ2278@serenity.lan","threadId":"33500","inReplyTo":"CALkWK0=6E=s6kJysMo2yC22c3pvCWn90S5neRyP0jpzpYrZboA@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-04-15T18:15:51Z","receivedAt":"2013-04-15T18:15:51Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, Apr 15, 2013 at 11:38:20PM +0530, Ramkumar Ramachandra wrote:\n> Junio C Hamano wrote:\n> > If \"rebase -m\" were to be taught to do this, the natural way to do\n> > so is to\n> >\n> >   (1) Prepare the todo the usual way\n> >   (2) Do those two commits for index and working tree\n> >   (3) Append two insns (exec reset HEAD^ and exec reset --soft\n> >       HEAD^) at the end of the rebase todo file.\n> \n> Er, no.  I don't want to touch the instruction sheet.  It becomes\n> especially problematic in -i, when the instruction sheet is\n> user-editable.\n> \n> > \"rebase--am\" could also be told to generate (on the preparation\n> > side) and notice (on the application side) a pair of patch files at\n> > the end that represent the index state and the working tree state\n> > and apply them without making the WIP part into a commit.\n> \n> Ugh, no.  I don't want to leak the implementation detail of autostash\n> into specific rebases.  Why can't I wrap the last statment in\n> git-rebase.sh in git stash/ git stash pop like I did with git-pull.sh?\n\nHow does that work with the following:\n\n- run_specific_rebase fails, so the user needs to fix it up and then run\n  \"git rebase --continue\".  We don't want to pop the stash in this case.\n\n- the user runs \"git rebase --continue\" with staged changes, knowing the\n  git-rebase will commit those.  We don't want to create a stash in this\n  case since it will remove the changes the user wants to commit.\n"},{"id":"214394","messageId":"vpqli8je8w0.fsf@grenoble-inp.fr","threadId":"33500","inReplyTo":"CALkWK0=6E=s6kJysMo2yC22c3pvCWn90S5neRyP0jpzpYrZboA@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-15T22:17:35Z","receivedAt":"2013-04-15T22:17:35Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> If \"rebase -m\" were to be taught to do this, the natural way to do\n>> so is to\n>>\n>>   (1) Prepare the todo the usual way\n>>   (2) Do those two commits for index and working tree\n>>   (3) Append two insns (exec reset HEAD^ and exec reset --soft\n>>       HEAD^) at the end of the rebase todo file.\n>\n> Er, no.  I don't want to touch the instruction sheet.  It becomes\n> especially problematic in -i, when the instruction sheet is\n> user-editable.\n\nI do not find this problematic. It shows the user what's going on. It\nmay be a good idea to append the last instructions after launching the\neditor if we want to partially hide it (but it's still going to be\nvisible with rebase --edit-todo)\n\n>> \"rebase--am\" could also be told to generate (on the preparation\n>> side) and notice (on the application side) a pair of patch files at\n>> the end that represent the index state and the working tree state\n>> and apply them without making the WIP part into a commit.\n>\n> Ugh, no.  I don't want to leak the implementation detail of autostash\n> into specific rebases.  Why can't I wrap the last statment in\n> git-rebase.sh in git stash/ git stash pop like I did with git-pull.sh?\n\nBecause \"git rebase\" needs multiple runs in case of conflicts. You have\nto store the information somewhere in the filesystem, not in a variable.\nWhat you need to store is whether you need to unstash, and where you are\nin the process (in Junio's version, you may be doing the actual rebase,\nor fixing conflicts in index state application, or fixing conflicts in\ntree state application, or done). Storing what you have to do and where\nyou are in the process really sounds like a job for the instruction\nsheet, no?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214422","messageId":"20130416030948.GJ3262@elie.Belkin","threadId":"33500","inReplyTo":"vpqbo9gqcvl.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-16T03:09:48Z","receivedAt":"2013-04-16T03:09:48Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Matthieu Moy wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n\n>> Yes, that is why I said for pull-merge, --authsquash is neutral-to-better\n>> and pull.autosquash is harmful.\n>\n> To speak from my experience: I find myself typing \"git stash && git pull\n> && git stash pop\" relatively often.\n\nTo that end, maybe \"git pull --stash\" would be an easier to type option\nname than \"git pull --autostash\".\n\nThat would also avoid the question of \"What is automatically going to\nhappen here?  Is it going to stash only sometimes?  Is it going to\nautomatically stash what I pull?\".\n\nI'm not a big stash user (except \"git stash --keep-index\" to prepare\nto test changes in the index), so I can't say much more about the\ndetails.\n\nThanks,\nJonathan\n"},{"id":"214424","messageId":"20130416031414.GK3262@elie.Belkin","threadId":"33500","inReplyTo":"CALkWK0nrVZo3MSgqpPmX2+T3JJ8uP=hzH3PMv+qd4ZaqNVwEsw@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-16T03:14:14Z","receivedAt":"2013-04-16T03:14:14Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Matthieu Moy wrote:\n\n>> No, you don't. Just try if you're not convinced:\n>\n> Oh, I trusted the documentation on this one and never tried with a\n> dirty worktree myself.  Please fix the documentation, if you know how\n> exactly to correct it.\n\nThe manual says:\n\n\t\"git pull\" and \"git merge\" will stop without doing anything when\n\tlocal uncommitted changes overlap with files that git pull/git\n\tmerge may need to update.\n\nThat accurately describes the behavior.\n\nI wouldn't be surprised if there's still a documentation bug, though:\na lack of clarity, a missing hint somewhere else, something else\nmisleading.  That seems especially likely when you say \"I trusted the\ndocumentation on this one\".  Care to point to the appropriate section,\nso it can be fixed?\n\nThanks,\nJonathan\n"},{"id":"214436","messageId":"CALkWK0=PemnwYkLg5X3YXA5kKE+K5rbbWvS+DR9xpTqAuq+QCg@mail.gmail.com","threadId":"33500","inReplyTo":"20130416031414.GK3262@elie.Belkin","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-16T04:55:50Z","receivedAt":"2013-04-16T04:55:50Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> I wouldn't be surprised if there's still a documentation bug, though:\n> a lack of clarity, a missing hint somewhere else, something else\n> misleading.  That seems especially likely when you say \"I trusted the\n> documentation on this one\".  Care to point to the appropriate section,\n> so it can be fixed?\n\nAs I pointed out in a previous email, I'm referring to the --abort\nsection of git-merge(1):\n\n\"If there were uncommitted worktree changes present when the merge\nstarted, git merge --abort will in some cases be unable to reconstruct\nthese changes. It is therefore recommended to always commit or stash\nyour changes before running git merge.\"\n\nMatthieu (and probably others) run git merge with a dirty worktree\nmost of the time, while I never do (because I read this section).\n"},{"id":"214437","messageId":"20130416052654.GA14567@elie.Belkin","threadId":"33500","inReplyTo":"CALkWK0=PemnwYkLg5X3YXA5kKE+K5rbbWvS+DR9xpTqAuq+QCg@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-16T05:26:54Z","receivedAt":"2013-04-16T05:26:54Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> \"If there were uncommitted worktree changes present when the merge\n> started, git merge --abort will in some cases be unable to reconstruct\n> these changes. It is therefore recommended to always commit or stash\n> your changes before running git merge.\"\n>\n> Matthieu (and probably others) run git merge with a dirty worktree\n> most of the time, while I never do (because I read this section).\n\nThe above says \"in some cases\".  It's presumably referring to the\ncase \"One exception is when the changed index entries are in the state\nthat would result from the merge already\" described in the\n\"PRE-MERGE CHECKS\" section.\n\nImproved wording welcome.\n\nCiao,\nJonathan\n"},{"id":"214468","messageId":"CALkWK0ndk7hPYk4pN8gmLxLOJR0XsLo1gwHB=n0QkK6DHgLzKQ@mail.gmail.com","threadId":"33500","inReplyTo":"vpqli8je8w0.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-16T09:20:15Z","receivedAt":"2013-04-16T09:20:15Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> Because \"git rebase\" needs multiple runs in case of conflicts. You have\n> to store the information somewhere in the filesystem, not in a variable.\n> What you need to store is whether you need to unstash, and where you are\n> in the process (in Junio's version, you may be doing the actual rebase,\n> or fixing conflicts in index state application, or fixing conflicts in\n> tree state application, or done). Storing what you have to do and where\n> you are in the process really sounds like a job for the instruction\n> sheet, no?\n\nNo.  Ultimately, the entry point of all these invocations is\ngit-rebase.sh.  The plan is to refactor calls from git-rebase.sh to\ngit-rebase--*.sh scripts so that those scripts return control to\ngit-rebase.sh, which will be the final exit point.  The logic is very\nsimple: On the very first invocation of rebase (ie. no existing rebase\nin progress), stash.  If the return statement from the specific rebase\nscript is 1 (which means that there are conflicts to be resolved),\nexit as usual.  If it is 0 (which means that the rebase completely\nsuccessfully), pop the stash before exiting as usual.\n\nWhat's so complicated about that?  I'm against leaking the autostash\nimplementation detail into specific rebases, because I value a clean\nand pleasant implementation over everything else.\n"},{"id":"214470","messageId":"vpqvc7mdd3x.fsf@grenoble-inp.fr","threadId":"33500","inReplyTo":"CALkWK0ndk7hPYk4pN8gmLxLOJR0XsLo1gwHB=n0QkK6DHgLzKQ@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-16T09:44:02Z","receivedAt":"2013-04-16T09:44:02Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> If it is 0 (which means that the rebase completely successfully), pop\n> the stash before exiting as usual.\n\nAnd you're going to pop the stash even if no stash were triggered when\nstarting the rebase.\n\nReally, think about it again: you're not going to guess whether you have\nto unstash without storing this information somewhere. You may argue\nabout storing it outside the todolist, you can't unstash\nunconditionally.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214472","messageId":"CALkWK0m+NQ_ZdDkD31VxEpFHGm006mGiAy6GHi31+MrPmzB1mQ@mail.gmail.com","threadId":"33500","inReplyTo":"vpqvc7mdd3x.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-16T09:55:30Z","receivedAt":"2013-04-16T09:55:30Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> And you're going to pop the stash even if no stash were triggered when\n> starting the rebase.\n>\n> Really, think about it again: you're not going to guess whether you have\n> to unstash without storing this information somewhere. You may argue\n> about storing it outside the todolist, you can't unstash\n> unconditionally.\n\nYes, touching a simple \"autostash\" file at stash-time, and removing it\nat pop-time will do.  I don't see why it should be part of a\n(potentially user-editable) todo-list, which serves an entirely\ndifferent purpose.\n"},{"id":"214475","messageId":"vpqppxudaor.fsf@grenoble-inp.fr","threadId":"33500","inReplyTo":"CALkWK0m+NQ_ZdDkD31VxEpFHGm006mGiAy6GHi31+MrPmzB1mQ@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-16T10:36:20Z","receivedAt":"2013-04-16T10:36:20Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Yes, touching a simple \"autostash\" file at stash-time, and removing it\n> at pop-time will do.  I don't see why it should be part of a\n> (potentially user-editable) todo-list, which serves an entirely\n> different purpose.\n\nYou'll have to apply the index state and then the tree state. How do you\nknow whether the next call to \"git rebase\" should apply one or the other?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214476","messageId":"vpqa9oyd8k2.fsf@grenoble-inp.fr","threadId":"33500","inReplyTo":"vpqppxudaor.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-16T11:22:21Z","receivedAt":"2013-04-16T11:22:21Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n>\n>> Yes, touching a simple \"autostash\" file at stash-time, and removing it\n>> at pop-time will do.  I don't see why it should be part of a\n>> (potentially user-editable) todo-list, which serves an entirely\n>> different purpose.\n>\n> You'll have to apply the index state and then the tree state. How do you\n> know whether the next call to \"git rebase\" should apply one or the other?\n\nPlus: what happens if the user ran \"git stash\" during rebase? In Junio's\nversion, the right commits are applied. Running blindly \"stash pop\" may\npop the wrong stash.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214496","messageId":"CABURp0qgxtcf_RCrobWr5Q_yiBraVOMDq9hWHrzP=EbZV46xiQ@mail.gmail.com","threadId":"33500","inReplyTo":"CALkWK0ndk7hPYk4pN8gmLxLOJR0XsLo1gwHB=n0QkK6DHgLzKQ@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-04-16T16:50:18Z","receivedAt":"2013-04-16T16:50:18Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Apr 16, 2013 at 5:20 AM, Ramkumar Ramachandra\n<artagnon@gmail.com> wrote:\n> Matthieu Moy wrote:\n> No.  Ultimately, the entry point of all these invocations is\n> git-rebase.sh.  The plan is to refactor calls from git-rebase.sh to\n> git-rebase--*.sh scripts so that those scripts return control to\n> git-rebase.sh, which will be the final exit point.  The logic is very\n> simple: On the very first invocation of rebase (ie. no existing rebase\n> in progress), stash.  If the return statement from the specific rebase\n> script is 1 (which means that there are conflicts to be resolved),\n> exit as usual.  If it is 0 (which means that the rebase completely\n> successfully), pop the stash before exiting as usual.\n>\n> What's so complicated about that?  I'm against leaking the autostash\n> implementation detail into specific rebases, because I value a clean\n> and pleasant implementation over everything else.\n\nIt can be more complex than you realize.\n\n   $ git pull --rebase --stash\n\n    It seems that there is already a .git/rebase-apply directory, and\n    I wonder if you are in the middle of another rebase.  If that is the\n    case, please try\n            git rebase (--continue | --abort | --skip)\n    If that is not the case, please\n            rm -fr .git/rebase-apply\n    and run me again.  I am stopping in case you still have something\n    valuable there.\n\nIf I follow the latter advice about 'rm -rf', who will remember that\n'rebase' had something stashed, and what will they do with it when\nthey do?\n\nWhat if it is weeks or months later?  I would be surprised to see\nlong-forgotten wip show up in my workspace all of a sudden.\n\nPhil\n"},{"id":"214502","messageId":"7vsj2qmkwv.fsf@alter.siamese.dyndns.org","threadId":"33500","inReplyTo":"vpqvc7mdd3x.fsf@grenoble-inp.fr","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-16T17:42:56Z","receivedAt":"2013-04-16T17:42:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n>\n>> If it is 0 (which means that the rebase completely successfully), pop\n>> the stash before exiting as usual.\n>\n> And you're going to pop the stash even if no stash were triggered when\n> starting the rebase.\n>\n> Really, think about it again: you're not going to guess whether you have\n> to unstash without storing this information somewhere. You may argue\n> about storing it outside the todolist, you can't unstash\n> unconditionally.\n\nYes, it can be part of todo, but it does not have to be.\n\nRegardless of where the information is stored, implementing the last\nstep as \"stash pop\" will add a small inconsistency the end user\nneeds to be aware of.\n\nImagine \"git rebase\" stops, asks you to help with conflicts, and you\nlook at it, play with the working tree, and made a mess.  If this\nwas the last \"stash pop\" invocation, the way to go back and start\nagain is \"reset --hard && stash pop\".  For all the other steps, that\nis not how the user goes back to the originally conflicted state in\norder to retry from scratch.\n\nMakes me wonder if the world were a better place if the rebase-todo\nlist were implemented as a dedicated stash and \"rebase --continue\"\nwere a mere \"stash pop\" followed by a commit if pop goes smoothly.\n\nI am not suggesting to actually do so, but it is an intriguing\nthought from the perspective of end user experience, isn't it?\n\nIn any case, I am not saying that it is a _bad_ thing to implement\nthe last \"restore the WIP\" stage as \"stash pop\". I am just pointing\nout that the messaging needs to be done carefully to make sure the\nuser understands which one is which, as the way to deal with the\nsituation where it stops and asks the user for help would be\ndifferent from normal step in the rebase sequence that replays a\ncommit.\n"},{"id":"214539","messageId":"CALkWK0nVfRETgT9U83Nn0QMg8MvdYWcFLzPELCj=8r6ZrR_KOw@mail.gmail.com","threadId":"33500","inReplyTo":"CABURp0qgxtcf_RCrobWr5Q_yiBraVOMDq9hWHrzP=EbZV46xiQ@mail.gmail.com","subject":"Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-16T20:53:14Z","receivedAt":"2013-04-16T20:53:14Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Phil Hord wrote:\n> If I follow the latter advice about 'rm -rf', who will remember that\n> 'rebase' had something stashed, and what will they do with it when\n> they do?\n>\n> What if it is weeks or months later?  I would be surprised to see\n> long-forgotten wip show up in my workspace all of a sudden.\n\nUltimately, I think an ideal implementation requires this entire\nautostash implementation to reside completely within the $state_dir.\nThe issue of a long-forgotten WIP is then the same issue as a\nlong-forgotten rebase, and a rm -rf $state_dir will get rid of the WIP\nas well.\n\nThe other reason is that it shouldn't interact with the rest of git.\nThis means no touching any refs or reflogs, and this can be\nproblematic if we decide to use the standard git stash.  I'm currently\nworking towards seeing if it's possible to get stash to create \"named\nstashes\" that we can predictably retrieve later, to avoid rolling our\nown homegrown stash.\n\nYes, the problem is much more complex than I initially thought.  It\nwas much simpler to implement it for git-pull.sh.\n"}]}