Han-Wen Nienhuys [off-list ref] writes:
quoted
Does "git cherry-pick --abort" only remove CHERRY_PICK_HEAD without
doing any other damage to the working tree files and to the index?
Good catch. I just added cherry-pick --abort without much thinking. I
reverted to update-ref -d which should be equivalent to what is
currently recommended.
I think that is a good change, although it is unfortunate that the
command line completion considers "git update-ref -d CHERRY_P<TAB>"
something it should help the user with.
I tried "cherry-pick --abort" to see what happens after
$ edit A B
$ git add A
$ git rev-parse HEAD~200 >.git/CHERRY_PICK_HEAD
$ git commit
and aborting the last "git commit" step. As "cherry-pick --abort"
involves running "git reset --merge" internally, of course some
states the user wanted to commit were wiped out and lost.
Thanks.