Undo commit breaks revision graph when it undoes a merge commit

[awilkins]

Description

Using the commit undo feature when the last commit is a merge commit breaks the principle of least surprise, and does not leave you in the state you were at before the commit (in an uncommitted merge).

Steps to Reproduce

1. Merge two branches with conflicts (e.g. feature, merging out from master)
2. Resolve conflicts
3. Commit your merge
   • Oops, you made a boo-boo
4. Undo this commit
5. Fix boo-boo
6. Recommit

Expected behavior:

Last commit in the graph has two ancestors, the previous head revisions of master and feature. It is a normal merge commit.

Actual behavior:

Last commit in the graph is now the equivalent of a cherry-pick of the diff from master into your feature branch. This commit only has one ancestor, the previous head of feature.

Reproduces how often:

Always

Versions

Ubuntu 16.04

$ atom-beta --version
Atom    : 1.28.0-beta1
Electron: 2.0.1
Chrome  : 61.0.3163.100
Node    : 8.9.3

$ apm-beta --version
apm  1.19.0
npm  3.10.10
node 6.9.5 x64
atom 1.28.0-beta1
python 2.7.12
git 2.7.4

[annthurium]

Thanks for reporting!

we just ran into this on a giant merge conflict! 😱

It might be good to either a) disable the undo button if the last commit is a merge commit and or b) prompt for confirmation and suggest amending instead.

In case anyone else runs into this in the meantime: you can use git reflog on the command line to find the merge commit before undoing, and reset hard to it.