BUG: git rebase -i -p silently looses commits

[Constantine Plotnikov <constantine.plotnikov@gmail.com>]

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