[buglet] gitk and git cherry-pick --abort interaction

[Chris Packham <judge.packham@gmail.com>]

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