Re: problem with git rebase -i

["Uwe Kleine-König" <Uwe.Kleine-Koenig@digi.com>]

Hello,

> 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