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@xxxxxxxxxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
