]> git.ipfire.org Git - thirdparty/git.git/commit - t/t3510-cherry-pick-sequence.sh
revert: do not remove state until sequence is finished
authorJonathan Nieder <jrnieder@gmail.com>
Sat, 10 Dec 2011 13:02:12 +0000 (07:02 -0600)
committerJunio C Hamano <gitster@pobox.com>
Mon, 12 Dec 2011 21:33:53 +0000 (13:33 -0800)
commit218b65fbf9428517e739b8bc26680c29910cf1cd
tree6af9e8e590c6af8fe9b53704a3a7ea9738d76e41
parent7acaaac275a1d338f7b2540779b7ea60f3f0667c
revert: do not remove state until sequence is finished

As v1.7.8-rc0~141^2~4 (2011-08-04) explains, git cherry-pick removes
the sequencer state just before applying the final patch.  In the
single-pick case, that was a good thing, since --abort and --continue
work fine without access to such state and removing it provides a
signal that git should not complain about the need to clobber it ("a
cherry-pick or revert is already in progress") in sequences like the
following:

git cherry-pick foo
git read-tree -m -u HEAD; # forget that; let's try a different one
git cherry-pick bar

After the recent patch "allow single-pick in the middle of cherry-pick
sequence" we don't need that hack any more.  In the new regime, a
traditional "git cherry-pick <commit>" command never looks at
.git/sequencer, so we do not need to cripple "git cherry-pick
<commit>..<commit>" for it any more.

So now you can run "git cherry-pick --abort" near the end of a
multi-pick sequence and it will abort the entire sequence, instead of
misbehaving and aborting just the final commit.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/revert.c
t/t3510-cherry-pick-sequence.sh