I've noticed that I've silently lost commits while running git rebase --interactive, and so I've recreated the issue in a simple repo for testing.
I have four commits, and I'd like to reorder two of them. Here's my starting commits:
55d4ca6 1 <-- origin/master
d70d325 2
b613c5b 3
2bd1177 4 <-- master
Each commit is independent of the others; all of them manipulate different files. I would like to reorder the commits to switch around commits 2 and 3. I'm going to do this with git rebase --interactive origin/master. Running that command gives me my commits in a vim window in this order, as expected:
pick d70d325 2
pick b613c5b 3
pick 2bd1177 4
I'm going to swap commits 2 and 3, so I reorder them in vim like so:
pick b613c5b 3
pick d70d325 2
pick 2bd1177 4
I would expect the two commits to be swapped, like so:
55d4ca6 1
bf330a8 3
5c6f9af 2
7cb8db1 4
In practice however one of my commits has simply disappeared, and my repo is left with this:
55d4ca6 1
7de7fb0 3
10fc3a7 4
Am I using rebase --interactive incorrectly? Or is this a bug in Git?
I'm on the latest Window Git version (1.9.5.msysgit.0). I've noticed this periodically over the last few months, over several Git versions.
Edit 1: Replaced vim and gitk images with text. Check out the original question revision if you want to see exactly what I'm seeing.
Because of a shortcut, the command I was actually running was git rebase --interactive --preserve-merges origin/master. Using these commands together and attempting to reorder commits is listed in the BUGS section of the git rebase documentation.
The BUGS section has a problem that's exactly equivalent to what I tried to describe above, and probably does a better job explaining what's going on.
The answer: you will drop commits while attempting to reorder using rebase --interactive --preserve-merges. Don't use the two together.