{"thread":{"id":"19202","subject":"Bug: 'git am --abort' can silently reset the wrong branch","startedAt":"2009-05-06T19:19:46Z","lastAt":"2009-05-25T22:23:54Z","messageCount":14,"participants":["Eduardo Habkost","Jeff King","Sverre Rabbelier","Junio C Hamano","Johannes Schindelin","Johannes Sixt","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"113114","messageId":"20090506191945.GG6325@blackpad","threadId":"19202","inReplyTo":null,"subject":"Bug: 'git am --abort' can silently reset the wrong branch","fromName":"Eduardo Habkost","fromEmail":"ehabkost@raisama.net","sentAt":"2009-05-06T19:19:46Z","receivedAt":"2009-05-06T19:19:46Z","isPatch":false,"sender":{"key":"ehabkost@raisama.net","avatar":null},"body":"Hi,\n\nI've ben bitten by this multiple times, while maintaining a multi-branch\nrepository. 'git am --abort' can drop the whole history of a branch, if you\nswitch branches before running it. Below are the steps to reproduce the\nproblem:\n\n[foo/branch1]$ git --version\ngit version 1.6.3.rc4.29.g8146\n\nI have two branches, with distinct changes:\n\n[foo/branch1]$ git diff branch1 branch2\ndiff --git a/file.txt b/file.txt\nindex e8a7b03..a11bf50 100644\n--- a/file.txt\n+++ b/file.txt\n@@ -1,2 +1,2 @@\n initial content\n-branch1 content, version 1\n+branch2 content. lots of changes here. version 12345.\n[foo/branch1]$ git status\n# On branch branch1\nnothing to commit (working directory clean)\n[foo/branch1]$\n\n\nI receive a patch and try to apply it to branch1:\n\n[foo/branch1]$ git am /tmp/patch.patch\nApplying: patch to be applied\nfatal: corrupt patch at line 13\nPatch failed at 0001 patch to be applied\nWhen you have resolved this problem run \"git am --resolved\".\nIf you would prefer to skip this patch, instead run \"git am --skip\".\nTo restore the original branch and stop patching run \"git am --abort\".\n[foo/branch1]$\n\n(Seeing that solving this conflict will take some time. I go out to grab some\ncoffee).\n\n(When back to work, somebody asks me to take a look on patch2.patch, that\napplies to branch2).\n\n[foo/branch1]$ git checkout branch2\nSwitched to branch 'branch2'\n[foo/branch2]$ git am /tmp/patch2.patch\nprevious rebase directory /tmp/foo/.git/rebase-apply still exists but mbox given.\n[foo/branch2]$\n\n\n(Oh, I see. There was a pending 'git am' operation. Let's just cancel it, I can\nstart it again later anyway).\n\nHere is where \"git am\" silently does the wrong thing:\n\n[foo/branch2]$ git am --abort\n[foo/branch2]$ cat file.txt\ninitial content\nbranch1 content, version 1\n[foo/branch2]$\n\n(Hey! where are the changes from branch2?)\n\n[foo/branch2]$ git diff branch1 branch2\n[foo/branch2]$\n\nOuch.   :(\n\n\nWhen that happens, I need to resort to git reflog, and manually git-reset\nbranch2 to point to the original commit.\n\nI don't know what would be the best approach to avoid this issue. I tested a\nsimilar scenario using 'git rebase' and 'git rebase --abort' switched back to\nbranch1 before resetting the branch state, instead of resetting branch2. Maybe\n'git am' could do the same.\n\n-- \nEduardo\n"},{"id":"113327","messageId":"20090508082826.GA29737@coredump.intra.peff.net","threadId":"19202","inReplyTo":"20090506191945.GG6325@blackpad","subject":"Re: Bug: 'git am --abort' can silently reset the wrong branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-05-08T08:28:26Z","receivedAt":"2009-05-08T08:28:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 06, 2009 at 04:19:46PM -0300, Eduardo Habkost wrote:\n\n> I've ben bitten by this multiple times, while maintaining a multi-branch\n> repository. 'git am --abort' can drop the whole history of a branch, if you\n> switch branches before running it. Below are the steps to reproduce the\n> problem:\n\nYeah, it would be nice if there was a safety valve here to cause \"git am\n--abort\" to realize that you had switched branches out from under it and\nnot bother with resetting HEAD (but it should still blow away\n.git/rebase-apply).\n\nBelow is a patch which accomplishes that. However, I'm not sure it is\nthe right direction. Switching branches and clobbering some other branch\nwith --abort is just _one_ thing you can do to screw yourself. You could\nalso have been doing useful work on the _same_ branch, and that would\nget clobbered by --abort.  However, I'm not sure if we have a good way\nof telling the difference between \"work which I did to try to get these\npatches to apply, but which should be thrown away when I abort\" and\n\"work which I did because I forgot I had an active git-am\".\n\nSo maybe just picking the changed-branch situation is the best we can\ndo. I'd be interested to hear comments from others.\n\nThis patch works for git-am; we would also need to do something similar\nfor rebase.\n\n-- >8 --\nam: try not to clobber alternate branches on --abort\n\nA user in the middle of a failed git-am may forget that they\nare there and begin doing other work. They may later realize\nthat the \"am\" session is still active (when trying to rebase\nor apply another patch), at which point they are tempted to\n\"git am --abort\". However, this resets their HEAD back to\nORIG_HEAD, clobbering any work they have done in the\nmeantime.\n\nThis patch detects the situation where the branch has\nchanged and skips the reset step (which assumes the user has\nthe tree in a state they like now).\n\n---\ndiff --git a/git-am.sh b/git-am.sh\nindex 6d1848b..4d5f408 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -244,10 +244,13 @@ then\n \t\t\texec git rebase --abort\n \t\tfi\n \t\tgit rerere clear\n-\t\ttest -f \"$dotest/dirtyindex\" || {\n+\t\tif ! test -f \"$dotest/dirtyindex\" &&\n+\t\t     test \"`git symbolic-ref -q HEAD`\" = \\\n+\t\t          \"`cat \"$dotest/start-ref\"`\"\n+\t\tthen\n \t\t\tgit read-tree --reset -u HEAD ORIG_HEAD\n \t\t\tgit reset ORIG_HEAD\n-\t\t}\n+\t\tfi\n \t\trm -fr \"$dotest\"\n \t\texit ;;\n \tesac\n@@ -304,6 +307,7 @@ else\n \t\t\tgit update-ref -d ORIG_HEAD >/dev/null 2>&1\n \t\tfi\n \tfi\n+\tgit symbolic-ref -q HEAD >\"$dotest/start-ref\"\n fi\n \n case \"$resolved\" in\ndiff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh\nindex 2b912d7..8e62e76 100755\n--- a/t/t4151-am-abort.sh\n+++ b/t/t4151-am-abort.sh\n@@ -62,4 +62,19 @@ do\n \n done\n \n+test_expect_success 'am --abort does not clobber changed branch' '\n+\trm -f otherfile-* &&\n+\tgit checkout -b other &&\n+\techo content >unrelated &&\n+\tgit add unrelated &&\n+\tgit commit -m other &&\n+\tgit rev-parse other >expect &&\n+\tgit checkout master &&\n+\ttest_must_fail git am 000[1245]-*.patch &&\n+\tgit checkout other &&\n+\tgit am --abort &&\n+\tgit rev-parse other >actual &&\n+\ttest_cmp expect actual\n+'\n+\n test_done\n"},{"id":"113328","messageId":"fabb9a1e0905080137v613d6b9hccd6d17149bd049f@mail.gmail.com","threadId":"19202","inReplyTo":"20090508082826.GA29737@coredump.intra.peff.net","subject":"Re: Bug: 'git am --abort' can silently reset the wrong branch","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-05-08T08:37:39Z","receivedAt":"2009-05-08T08:37:39Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Fri, May 8, 2009 at 10:28, Jeff King <peff@peff.net> wrote:\n> So maybe just picking the changed-branch situation is the best we can\n> do. I'd be interested to hear comments from others.\n\nFWIW, I usually use 'git am' on accident (when trying to type somthing\nelse :P), and I would prefer if 'git am --abort' would just clean up\nit's own mess, but leave my working dir alone. If I want to obliterate\nmy data I can 'git reset --hard' myself.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"113333","messageId":"7v7i0s0y03.fsf@alter.siamese.dyndns.org","threadId":"19202","inReplyTo":"20090508082826.GA29737@coredump.intra.peff.net","subject":"Re: Bug: 'git am --abort' can silently reset the wrong branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-08T09:01:16Z","receivedAt":"2009-05-08T09:01:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Switching branches and clobbering some other branch\n> with --abort is just _one_ thing you can do to screw yourself. You could\n> also have been doing useful work on the _same_ branch, and that would\n> get clobbered by --abort.  However, I'm not sure if we have a good way\n> of telling the difference between \"work which I did to try to get these\n> patches to apply, but which should be thrown away when I abort\" and\n> \"work which I did because I forgot I had an active git-am\".\n\nI think I've said this already, but honestly speaking, I think --abort\nshould not do --reset at all, but just remove the $dotest directory.  Or\nperhaps introduce a --clear option to do so.\n\nAt least your patch is an improvement.\n\nWhat I sometimes see to my users happen is to try applying to the oldest\nintegration branch the patch (the users think) ought to apply, see it fail\nto apply, switch to a bit newer branch and run \"am\" again (trusting that\nit will pick up the material from $dotest), repeat the above and then give\nup with \"git am --abort\".  I do not think anybody can offhand explain to\nwhich branch and to what state the command takes the user back to in such\na situation without looking at what the code actually does X-<; even\nthough I think it should take the user back to the original branch, I do\nnot think that is what the code does.\n"},{"id":"113335","messageId":"20090508091218.GC29737@coredump.intra.peff.net","threadId":"19202","inReplyTo":"7v7i0s0y03.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: 'git am --abort' can silently reset the wrong branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-05-08T09:12:18Z","receivedAt":"2009-05-08T09:12:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 08, 2009 at 02:01:16AM -0700, Junio C Hamano wrote:\n\n> > Switching branches and clobbering some other branch\n> > with --abort is just _one_ thing you can do to screw yourself. You could\n> > also have been doing useful work on the _same_ branch, and that would\n> > get clobbered by --abort.  However, I'm not sure if we have a good way\n> > of telling the difference between \"work which I did to try to get these\n> > patches to apply, but which should be thrown away when I abort\" and\n> > \"work which I did because I forgot I had an active git-am\".\n> \n> I think I've said this already, but honestly speaking, I think --abort\n> should not do --reset at all, but just remove the $dotest directory.  Or\n> perhaps introduce a --clear option to do so.\n\nI assumed that people actually liked the current \"reset\" behavior, so I\ndidn't want to propose getting rid of it.  Personally, I hate it. So I\nwould be very happy to see it ripped out entirely, and then that neatly\nsolves the problem (i.e., it now errs on the side of not throwing away\nwork).\n\n> What I sometimes see to my users happen is to try applying to the oldest\n> integration branch the patch (the users think) ought to apply, see it fail\n> to apply, switch to a bit newer branch and run \"am\" again (trusting that\n> it will pick up the material from $dotest), repeat the above and then give\n> up with \"git am --abort\".  I do not think anybody can offhand explain to\n> which branch and to what state the command takes the user back to in such\n> a situation without looking at what the code actually does X-<; even\n> though I think it should take the user back to the original branch, I do\n> not think that is what the code does.\n\nNo, the current code clobbers whatever is in the current HEAD with\nORIG_HEAD. So not only might you set another random branch back to the\noriginally am'd branch, but if you did a pull in between you can pick up\nsome random commit.\n\n-Peff\n"},{"id":"114654","messageId":"20090525104308.GA26775@coredump.intra.peff.net","threadId":"19202","inReplyTo":"20090508091218.GC29737@coredump.intra.peff.net","subject":"[RFC PATCH] am: do not do any reset on --abort","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-05-25T10:43:09Z","receivedAt":"2009-05-25T10:43:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"We really have no idea what state the tree is in at this\npoint, and whether the user might have done useful work on\ntop of it. So let's err on the side of keeping the user's\ndata intact.\n\nThe downside is that if they do have cruft to get rid of, or\nwant to pretend as if earlier parts of the series that were\napplied did not exist, they must manually \"git reset --hard\"\nnow.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nThis is a followup to:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/118373\n\n git-am.sh |    4 ----\n 1 files changed, 0 insertions(+), 4 deletions(-)\n\ndiff --git a/git-am.sh b/git-am.sh\nindex 578780b..a7e24cf 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -240,10 +240,6 @@ then\n \t\t\texec git rebase --abort\n \t\tfi\n \t\tgit rerere clear\n-\t\ttest -f \"$dotest/dirtyindex\" || {\n-\t\t\tgit read-tree --reset -u HEAD ORIG_HEAD\n-\t\t\tgit reset ORIG_HEAD\n-\t\t}\n \t\trm -fr \"$dotest\"\n \t\texit ;;\n \tesac\n-- \n1.6.3.1.250.g01b8b.dirty\n"},{"id":"114661","messageId":"alpine.DEB.1.00.0905251348050.4288@intel-tinevez-2-302","threadId":"19202","inReplyTo":"20090525104308.GA26775@coredump.intra.peff.net","subject":"Re: [RFC PATCH] am: do not do any reset on --abort","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-05-25T11:49:18Z","receivedAt":"2009-05-25T11:49:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 25 May 2009, Jeff King wrote:\n\n> We really have no idea what state the tree is in at this\n> point, and whether the user might have done useful work on\n> top of it. So let's err on the side of keeping the user's\n> data intact.\n> \n> The downside is that if they do have cruft to get rid of, or\n> want to pretend as if earlier parts of the series that were\n> applied did not exist, they must manually \"git reset --hard\"\n> now.\n> \n> Signed-off-by: Jeff King <peff@peff.net>\n\nHmm.  I think I would revert that patch after merging git.git right away.\n\nCan you at least check for a dirty tree and reset --hard if it is clean?  \nIn the other case, you could still say \"you seem to have modifications, \nbla bla bla\"...\n\nCiao,\nDscho\n"},{"id":"114664","messageId":"20090525120019.GA1740@coredump.intra.peff.net","threadId":"19202","inReplyTo":"alpine.DEB.1.00.0905251348050.4288@intel-tinevez-2-302","subject":"Re: [RFC PATCH] am: do not do any reset on --abort","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-05-25T12:00:19Z","receivedAt":"2009-05-25T12:00:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 25, 2009 at 01:49:18PM +0200, Johannes Schindelin wrote:\n\n> > We really have no idea what state the tree is in at this\n> > point, and whether the user might have done useful work on\n> > top of it. So let's err on the side of keeping the user's\n> > data intact.\n> > \n> > The downside is that if they do have cruft to get rid of, or\n> > want to pretend as if earlier parts of the series that were\n> > applied did not exist, they must manually \"git reset --hard\"\n> > now.\n> \n> Hmm.  I think I would revert that patch after merging git.git right away.\n\nYou know, you can just say you don't like it. ;)\n\n> Can you at least check for a dirty tree and reset --hard if it is clean?\n\nNo, that would defeat the purpose. The problem is that we have no idea\nwhat has happened since the initial \"git am\". The user may have made\ncommits they want to keep, and we don't want to reset those away. They\nmay even have pulled, which means ORIG_HEAD can no longer be trusted for\na reset.\n\n> In the other case, you could still say \"you seem to have modifications, \n> bla bla bla\"...\n\nI think you raise a good point here. If we do decide to stop doing the\nreset automatically, it is probably better not to simply stop doing it\n(as my patch does), but to downgrade it to a warning (\"You probably want\nto reset, etc...\").\n\n-Peff\n"},{"id":"114667","messageId":"4A1A8C6C.5020009@viscovery.net","threadId":"19202","inReplyTo":"20090525120019.GA1740@coredump.intra.peff.net","subject":"Re: [RFC PATCH] am: do not do any reset on --abort","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-05-25T12:17:48Z","receivedAt":"2009-05-25T12:17:48Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Jeff King schrieb:\n> On Mon, May 25, 2009 at 01:49:18PM +0200, Johannes Schindelin wrote:\n> \n>>> We really have no idea what state the tree is in at this\n>>> point, and whether the user might have done useful work on\n>>> top of it. So let's err on the side of keeping the user's\n>>> data intact.\n>>>\n>>> The downside is that if they do have cruft to get rid of, or\n>>> want to pretend as if earlier parts of the series that were\n>>> applied did not exist, they must manually \"git reset --hard\"\n>>> now.\n>> Hmm.  I think I would revert that patch after merging git.git right away.\n> \n> You know, you can just say you don't like it. ;)\n> \n>> Can you at least check for a dirty tree and reset --hard if it is clean?\n> \n> No, that would defeat the purpose. The problem is that we have no idea\n> what has happened since the initial \"git am\". The user may have made\n> commits they want to keep, and we don't want to reset those away. They\n> may even have pulled, which means ORIG_HEAD can no longer be trusted for\n> a reset.\n\nI wonder why we have this problem (and do something about it) with git-am,\nbut not with git-rebase. Is it perhaps that the usual case were people\nwere bitten by the old behavior is:\n\n   $ git am mbox\n   .... stops with conflicts\n   .... oops, wrong branch\n   $ git checkout other-branch\n   $ git am mbox\n   error: git am is already in progress\n   $ git am --abort\n   OUTCH! other-branch was reset!\n\nrebase is not used in this manner, and even though it does reset --hard,\nit doesn't hurt (that often).\n\n-- Hannes\n"},{"id":"114674","messageId":"32541b130905250854v981277oe093ee4990726a2a@mail.gmail.com","threadId":"19202","inReplyTo":"4A1A8C6C.5020009@viscovery.net","subject":"Re: [RFC PATCH] am: do not do any reset on --abort","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-05-25T15:54:36Z","receivedAt":"2009-05-25T15:54:36Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, May 25, 2009 at 8:17 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:\n>   $ git am --abort\n>   OUTCH! other-branch was reset!\n\nIf *that's* your problem, then presumably you could avoid it just by\nchecking whether the right branch corresponds to HEAD before doing a\nreset.\n\nHave fun,\n\nAvery\n"},{"id":"114675","messageId":"20090525160020.GA5449@coredump.intra.peff.net","threadId":"19202","inReplyTo":"32541b130905250854v981277oe093ee4990726a2a@mail.gmail.com","subject":"Re: [RFC PATCH] am: do not do any reset on --abort","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-05-25T16:00:20Z","receivedAt":"2009-05-25T16:00:20Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 25, 2009 at 11:54:36AM -0400, Avery Pennarun wrote:\n\n> On Mon, May 25, 2009 at 8:17 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:\n> >   $ git am --abort\n> >   OUTCH! other-branch was reset!\n> \n> If *that's* your problem, then presumably you could avoid it just by\n> checking whether the right branch corresponds to HEAD before doing a\n> reset.\n\nBut that only covers one problem. How about you forgot that you had a\nfailed am in progress, waited hours or days, made some commits on the\nsame branch, tried to am a series, got the \"in progress\" message and\nthen did an \"--abort\"?\n\nAnd yes, I have done that.\n\nIn both examples, an alternative method for dealing with this is to try\nto alert the user that we are in the middle of an am when doing\npotentially suspicious things (like switching branches or making commits\noutside of \"git am --resolved\"). I don't know how well that would work\nin practice.\n\n-Peff\n"},{"id":"114677","messageId":"20090525160207.GB5449@coredump.intra.peff.net","threadId":"19202","inReplyTo":"4A1A8C6C.5020009@viscovery.net","subject":"Re: [RFC PATCH] am: do not do any reset on --abort","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-05-25T16:02:07Z","receivedAt":"2009-05-25T16:02:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 25, 2009 at 02:17:48PM +0200, Johannes Sixt wrote:\n\n> I wonder why we have this problem (and do something about it) with git-am,\n> but not with git-rebase. Is it perhaps that the usual case were people\n> were bitten by the old behavior is:\n\nI don't know. I had assumed a safety valve we put in git-am might need\nto be matched in rebase. But I don't recall whether I have screwed\nmyself in the same way with rebase. Perhaps because rebase happens on a\ndetached HEAD, I tend to notice sooner that something is not right.\n\n-Peff\n"},{"id":"114679","messageId":"32541b130905250910r251e4667m2b63b651e1724b59@mail.gmail.com","threadId":"19202","inReplyTo":"20090525160207.GB5449@coredump.intra.peff.net","subject":"Re: [RFC PATCH] am: do not do any reset on --abort","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-05-25T16:10:21Z","receivedAt":"2009-05-25T16:10:21Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, May 25, 2009 at 12:02 PM, Jeff King <peff@peff.net> wrote:\n> On Mon, May 25, 2009 at 02:17:48PM +0200, Johannes Sixt wrote:\n>\n>> I wonder why we have this problem (and do something about it) with git-am,\n>> but not with git-rebase. Is it perhaps that the usual case were people\n>> were bitten by the old behavior is:\n>\n> I don't know. I had assumed a safety valve we put in git-am might need\n> to be matched in rebase. But I don't recall whether I have screwed\n> myself in the same way with rebase. Perhaps because rebase happens on a\n> detached HEAD, I tend to notice sooner that something is not right.\n\nAh, maybe that's the difference.  rebase seems to detach the HEAD,\nthen do a bunch of stuff, then reset the original branch only when\nit's done.  So aborting doesn't reset any branches at all, it just\nchecks out the original branch.\n\nThus one option would be to try to make am more like rebase: detach\nthe HEAD before it starts, and reattach it only on success.  At least\nthen you only have one set of UI problems to fix.\n\n(Of course, I've gotten myself into trouble anyway by checking new\nstuff in on the detached HEAD and later aborting a rebase.  I have\nquite a love-hate relationship with detached HEADs.)\n\nMaybe the best solution here isn't to prevent people from shooting\nthemselves in the foot, but instead to help them recover afterwards.\nI've noticed most people don't know about 'git reflog'; they often\nseem astonished when I tell them about it.  reflog + not blowing away\ndirty repositories would mean that you're always safe.\n\nHave fun,\n\nAvery\n"},{"id":"114712","messageId":"7vvdnou8hx.fsf@alter.siamese.dyndns.org","threadId":"19202","inReplyTo":"20090525104308.GA26775@coredump.intra.peff.net","subject":"Re: [RFC PATCH] am: do not do any reset on --abort","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-25T22:23:54Z","receivedAt":"2009-05-25T22:23:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> We really have no idea what state the tree is in at this\n> point, and whether the user might have done useful work on\n> top of it. So let's err on the side of keeping the user's\n> data intact.\n>\n> The downside is that if they do have cruft to get rid of, or\n> want to pretend as if earlier parts of the series that were\n> applied did not exist, they must manually \"git reset --hard\"\n> now.\n\nI do not see it as a major downside, but not telling them that they may\nwant to when we avoid doing it ourselves might be.\n\n> Signed-off-by: Jeff King <peff@peff.net>\n> ---\n> This is a followup to:\n>\n>   http://thread.gmane.org/gmane.comp.version-control.git/118373\n>\n>  git-am.sh |    4 ----\n>  1 files changed, 0 insertions(+), 4 deletions(-)\n>\n> diff --git a/git-am.sh b/git-am.sh\n> index 578780b..a7e24cf 100755\n> --- a/git-am.sh\n> +++ b/git-am.sh\n> @@ -240,10 +240,6 @@ then\n>  \t\t\texec git rebase --abort\n>  \t\tfi\n>  \t\tgit rerere clear\n> -\t\ttest -f \"$dotest/dirtyindex\" || {\n> -\t\t\tgit read-tree --reset -u HEAD ORIG_HEAD\n> -\t\t\tgit reset ORIG_HEAD\n> -\t\t}\n>  \t\trm -fr \"$dotest\"\n>  \t\texit ;;\n>  \tesac\n> -- \n> 1.6.3.1.250.g01b8b.dirty\n"}]}