Re: rebase -p confusion in 1.6.1

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Jan 15, 2009, 13:39 UTC
Message-ID: <496F3C99.1040800@drmicha.warpmail.net>
In-Reply-To: <slrngmu4j5.e1u.sitaramc@sitaramc.homelinux.net>

Sitaram Chamarty venit, vidit, dixit 15.01.2009 11:39:

Show 49 quoted lines

> 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