Re: BUG: git rebase -i -p silently looses commits

[demerphq <demerphq@gmail.com>]

2009/11/2 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.

Doesnt -p ONLY work for interactive rebase?

       -p, --preserve-merges
           Instead of ignoring merges, try to recreate them. This
option only works in interactive mode.

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"