Re: problem with git rebase -i

From: Uwe Kleine-König <uwe.kleine-koenig@digi.com>
Date: Feb 13, 2008, 09:29 UTC
Message-ID: <20080213092910.GA20219@digi.com>
In-Reply-To: <20080213081059.GA18230@digi.com>

Hello,

Show 20 quoted lines

> Uwe Kleine-König wrote:
> > I tried to rebase my work (on the Linux kernel) to current Linus'
> > master.  As I have two branches I merged them and ran:
> > 
> > 	git rebase -i -p v2.6.25-rc1
> > 
> > But then the list I got in my editor didn't include the merge and so the
> > result was broken.
> > 
> > If I add
> > 
> > 	pick 913183f
> > 
> > (with 913183f being my HEAD) to the list, the result is correct.
> > 
> > The reason that my merge is missing is that git rev-list thinks my
> > merge is the same as 249d621 and so skips that as it uses --cherry-pick.
> I think the right thing to do here is to let --cherry-pick only kick out
> revs that are no merges.  This should be save as git-rebase--interactive
> is the only user of --cherry-pick.

After some debugging I found the problem.

I created 913183f with

	git merge --no-ff -s ours branch1 branch2

while HEAD was on an ancestor of v2.6.25-rc1. As patch_id uses the diff to the first parent the result was the id of an empty patch. As 249d621 is empty, too, 913183f was skipped.

@Len: The log message of 249d621 suggests that this should be a merge, but it only has one parent. Did you lost some commits here?

I didn't try it, but I assume that if I hadn't used --no-ff to create 913183f it would have worked.

Nonetheless I think that kicking out 913183f is wrong. In my eyes the fix must result in

	patch-id(913183f) != patch-id(249d621)

So probably the combined diff should be used to calculate the patch id?

I don't understand the git code here, but I will provide a test in a follow-up mail.

Best regards Uwe

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962