"git rebase --interactive" is silently dropping commits while attempting to reorder them

Question

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.

Answer 1

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.