Re: problem with git rebase -i

Hello,

Uwe Kleine-König wrote:

quoted

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