BUG: git rebase -i -p silently looses commits

I have encountered what looks like critical bugs in the git rebase -i -p (it can be reproduced on mingw and cygwin, I have not tried other platforms).

Let's create a git repository with

git init # the next line is for mingw git config core.autocrlf input echo a >a.txt echo b >b.txt git add a.txt b.txt git commit -m "init commit" echo aa >a.txt git add a.txt git commit -m "aa commit" echo bb >b.txt git add b.txt git commit -m "bb commit" echo aaa >a.txt git add a.txt git commit -m "aaa commit"

Now let's use the following rebase command:

git rebase -i -p HEAD~3

When the editor will appear, just move the commit "bb commit" to the end of the list. The rebase process will complete successfully, but commit "aaa commit" will be missing from the history and working tree will not be affected by that commit.

Other bug is that if we move "bb commit" to the top of the list in the editor, the rebase process will apply "bb commit", but instead of applying "aa commit" and than "aaa commit", the rebase process fails with a merge conflict.

This can be reproduced with git 1.6.5.1 (msys) and 1.6.1.2 (cygwin). I consider these to be a critical bugs that make "-p" option extremely dangerous for interactive rebase. It might even make sense to disable it for interactive rebase until the bug is fixed.

Regards, Constantine