git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Eduardo Habkost <ehabkost@raisama.net>
Cc: git@vger.kernel.org
Subject: Re: Bug: 'git am --abort' can silently reset the wrong branch
Date: Fri, 8 May 2009 04:28:26 -0400	[thread overview]
Message-ID: <20090508082826.GA29737@coredump.intra.peff.net> (raw)
In-Reply-To: <20090506191945.GG6325@blackpad>

On Wed, May 06, 2009 at 04:19:46PM -0300, Eduardo Habkost wrote:

> 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:

Yeah, it would be nice if there was a safety valve here to cause "git am
--abort" to realize that you had switched branches out from under it and
not bother with resetting HEAD (but it should still blow away
.git/rebase-apply).

Below is a patch which accomplishes that. However, I'm not sure it is
the right direction. Switching branches and clobbering some other branch
with --abort is just _one_ thing you can do to screw yourself. You could
also have been doing useful work on the _same_ branch, and that would
get clobbered by --abort.  However, I'm not sure if we have a good way
of telling the difference between "work which I did to try to get these
patches to apply, but which should be thrown away when I abort" and
"work which I did because I forgot I had an active git-am".

So maybe just picking the changed-branch situation is the best we can
do. I'd be interested to hear comments from others.

This patch works for git-am; we would also need to do something similar
for rebase.

-- >8 --
am: try not to clobber alternate branches on --abort

A user in the middle of a failed git-am may forget that they
are there and begin doing other work. They may later realize
that the "am" session is still active (when trying to rebase
or apply another patch), at which point they are tempted to
"git am --abort". However, this resets their HEAD back to
ORIG_HEAD, clobbering any work they have done in the
meantime.

This patch detects the situation where the branch has
changed and skips the reset step (which assumes the user has
the tree in a state they like now).

---
diff --git a/git-am.sh b/git-am.sh
index 6d1848b..4d5f408 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -244,10 +244,13 @@ then
 			exec git rebase --abort
 		fi
 		git rerere clear
-		test -f "$dotest/dirtyindex" || {
+		if ! test -f "$dotest/dirtyindex" &&
+		     test "`git symbolic-ref -q HEAD`" = \
+		          "`cat "$dotest/start-ref"`"
+		then
 			git read-tree --reset -u HEAD ORIG_HEAD
 			git reset ORIG_HEAD
-		}
+		fi
 		rm -fr "$dotest"
 		exit ;;
 	esac
@@ -304,6 +307,7 @@ else
 			git update-ref -d ORIG_HEAD >/dev/null 2>&1
 		fi
 	fi
+	git symbolic-ref -q HEAD >"$dotest/start-ref"
 fi
 
 case "$resolved" in
diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh
index 2b912d7..8e62e76 100755
--- a/t/t4151-am-abort.sh
+++ b/t/t4151-am-abort.sh
@@ -62,4 +62,19 @@ do
 
 done
 
+test_expect_success 'am --abort does not clobber changed branch' '
+	rm -f otherfile-* &&
+	git checkout -b other &&
+	echo content >unrelated &&
+	git add unrelated &&
+	git commit -m other &&
+	git rev-parse other >expect &&
+	git checkout master &&
+	test_must_fail git am 000[1245]-*.patch &&
+	git checkout other &&
+	git am --abort &&
+	git rev-parse other >actual &&
+	test_cmp expect actual
+'
+
 test_done

  reply	other threads:[~2009-05-08  8:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-06 19:19 Bug: 'git am --abort' can silently reset the wrong branch Eduardo Habkost
2009-05-08  8:28 ` Jeff King [this message]
2009-05-08  8:37   ` Sverre Rabbelier
2009-05-08  9:01   ` Junio C Hamano
2009-05-08  9:12     ` Jeff King
2009-05-25 10:43       ` [RFC PATCH] am: do not do any reset on --abort Jeff King
2009-05-25 11:49         ` Johannes Schindelin
2009-05-25 12:00           ` Jeff King
2009-05-25 12:17             ` Johannes Sixt
2009-05-25 15:54               ` Avery Pennarun
2009-05-25 16:00                 ` Jeff King
2009-05-25 16:02               ` Jeff King
2009-05-25 16:10                 ` Avery Pennarun
2009-05-25 22:23         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090508082826.GA29737@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=ehabkost@raisama.net \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).