summaryrefslogtreecommitdiff
path: root/Documentation/manpage-1.72.xsl
diff options
context:
space:
mode:
authorLibravatar Jonathan Nieder <jrnieder@gmail.com>2011-12-10 07:02:12 -0600
committerLibravatar Junio C Hamano <gitster@pobox.com>2011-12-12 13:33:53 -0800
commit218b65fbf9428517e739b8bc26680c29910cf1cd (patch)
tree6af9e8e590c6af8fe9b53704a3a7ea9738d76e41 /Documentation/manpage-1.72.xsl
parentrevert: allow single-pick in the middle of cherry-pick sequence (diff)
downloadtgif-218b65fbf9428517e739b8bc26680c29910cf1cd.tar.xz
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>
Diffstat (limited to 'Documentation/manpage-1.72.xsl')
0 files changed, 0 insertions, 0 deletions