Re: rebase -p confusion in 1.6.1

[Michael J Gruber <git@drmicha.warpmail.net>]

Sitaram Chamarty venit, vidit, dixit 15.01.2009 11:39:
> Hello all,
> 
> While trying to understand "rebase -p", I came across some
> very unexpected behaviour that made me throw in the towel
> and ask for help!
> 
> The outputs I got really confused me.  Before the "rebase
> -p", the tree looked like
>     
>     * 78ffda9... (refs/heads/work) b4
>     * be1e3a4... b3
>     *   cd8d893... Merge branch 'master' into work
>     |\
>     | * 0153c27... (refs/heads/master) a4
>     | * 74f4387... a3
>     * | f1b0c1c... b2
>     * | 2e202d0... b1
>     |/
>     * b37ae36... a2
>     * ed1e1bc... a1
> 
> But afterward, this is what it looks like -- all the "b"
> commits are gone!
> 
>     * 0153c27... (refs/heads/work, refs/heads/master) a4
>     * 74f4387... a3
>     * b37ae36... a2
>     * ed1e1bc... a1
> 
> What did I do wrong/misunderstand?
> 
> Here's how to recreate.  Note that "testci" is a shell
> function and "lg" is a git alias.  They are, respectively,
> (1) testci() { for i; do echo $i > $i; git add $i; git commit -m $i; done; }
> (2) git config alias.lg log --graph --pretty=oneline --abbrev-commit --decorate
> 
>     git init
>     testci a1 a2
>     git checkout -b work
>     testci b1 b2
>     git checkout master
>     testci a3 a4
>     git checkout work
>     git merge master
>     testci b3 b4
>     git --no-pager lg   # graph before rebase -p
>     git rebase -p master
>     git --no-pager lg   # graph after rebase -p
> 

First of all: git 1.6.0.6 gives you the unchanged graph after using
rebase -i -p (git 1.6.1 adds -i behind you back and sets up a dummy
editor). In any case, git rebase should not simply eat those commits -
either leave them alone or rewrite them. git bisect says

d80d6bc146232d81f1bb4bc58e5d89263fd228d4 is first bad commit
commit d80d6bc146232d81f1bb4bc58e5d89263fd228d4
Author: Stephen Haberman <stephen@exigencecorp.com>
Date:   Wed Oct 15 02:44:39 2008 -0500

    rebase-i-p: do not include non-first-parent commits touching UPSTREAM

so I'll cc the bad guy ;)

Second, what result do you expect? If the merge is to be preserved then
b1, b2 can't be simply ripped out - or else you get the linear structure
which rebase without '-p' delivers. The merge base (as returned by git
merge-base) between work and master is a4, i.e. master, so that the
expected result with '-p' is the one from 1.6.0.6 (unchanged graph).

Cheers,
Michael