Apologies 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 --abort
Thanks,
Chris
