Chris PackhamApologies in advance for the vagueness of this bug report.
I was juggling a few patches around in a git repo (happens to be linux but that's probably not particularly relevant).
I'd been reverting, rebasing and cherry-picking on the CLI. Then I found I needed one more commit which I located with gitk. Since it was already open I used the cherry-pick option within gitk, there were conflicts and gitk invoked git citool for me.
At that point I decided to bail on the cherry-pick and closed citool and gitk and ran git cherry-pick --abort from the command line and that’s where things got weird. The abort put me on a different commit than where I started (which happened to be the commit from a previous am --abort). I'm guessing gitk's cherry-pick doesn't fully record the information in a way that the cli counterpart expects.
I'll try and get a reproduction going but in the meantime some info from my terminal history and reflog might help.
$ git --version git version 2.15.0
$ cd linux/ linux (edac u+10)$ gitk # not pictured here cherry-picking one commit in gitk and citool running linux (edac *+|CHERRY-PICKING u+10)$ linux (edac *+|CHERRY-PICKING u+10)$ git cherry-pick --abort linux (edac u+13)$
Here's some info from the reflog abridged so gmail doesn't eat it.
linux (edac u+13)$ git reflog
d2b10042ccaf (HEAD -> edac) HEAD@{0}: reset: moving to d2b10042ccaf
67ebefac4b7e HEAD@{1}: rebase -i (finish): returning to refs/heads/edac
... HEAD@{2} through HEAD@{33} are rebase/commit/am/cherry-pick
d2b10042ccaf (HEAD -> edac) HEAD@{34}: am --abortThanks, Chris