Hi, I've ben bitten by this multiple times, while maintaining a multi-branch repository. 'git am --abort' can drop the whole history of a branch, if you switch branches before running it. Below are the steps to reproduce the problem: [foo/branch1]$ git --version git version 1.6.3.rc4.29.g8146 I have two branches, with distinct changes: [foo/branch1]$ git diff branch1 branch2 diff --git a/file.txt b/file.txt index e8a7b03..a11bf50 100644 --- a/file.txt +++ b/file.txt @@ -1,2 +1,2 @@ initial content -branch1 content, version 1 +branch2 content. lots of changes here. version 12345. [foo/branch1]$ git status # On branch branch1 nothing to commit (working directory clean) [foo/branch1]$ I receive a patch and try to apply it to branch1: [foo/branch1]$ git am /tmp/patch.patch Applying: patch to be applied fatal: corrupt patch at line 13 Patch failed at 0001 patch to be applied When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". [foo/branch1]$ (Seeing that solving this conflict will take some time. I go out to grab some coffee). (When back to work, somebody asks me to take a look on patch2.patch, that applies to branch2). [foo/branch1]$ git checkout branch2 Switched to branch 'branch2' [foo/branch2]$ git am /tmp/patch2.patch previous rebase directory /tmp/foo/.git/rebase-apply still exists but mbox given. [foo/branch2]$ (Oh, I see. There was a pending 'git am' operation. Let's just cancel it, I can start it again later anyway). Here is where "git am" silently does the wrong thing: [foo/branch2]$ git am --abort [foo/branch2]$ cat file.txt initial content branch1 content, version 1 [foo/branch2]$ (Hey! where are the changes from branch2?) [foo/branch2]$ git diff branch1 branch2 [foo/branch2]$ Ouch. :( When that happens, I need to resort to git reflog, and manually git-reset branch2 to point to the original commit. I don't know what would be the best approach to avoid this issue. I tested a similar scenario using 'git rebase' and 'git rebase --abort' switched back to branch1 before resetting the branch state, instead of resetting branch2. Maybe 'git am' could do the same. -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html