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 - 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
