problem with git rebase -i

Hello,

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.

Currently I cannot reproduce that with a simple testcase. I don't want to publish my tree now, but I can provide a bundle if someone wants to look into that.

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

Hello,

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.

Comments?

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

Hello,

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

Currently rev-list --cherry-pick kicks out two commits if they introduce the same change to their first parent and ignores other parents. This can be bad if both sides used the ours strategy to supersede old development branches.

---
 t/t6007-rev-list-cherry-pick-file.sh |   14 +++++++++++++-
 1 files changed, 13 insertions(+), 1 deletions(-)

Hello,

I'm not sure if combined diff is the right term. I'm open for a better one.

Moreover I'm not happy with the shortlog, maybe someone has a better suggestion?

index 4b8611c..26f62e1 100755
@@ -29,7 +29,13 @@ test_expect_success setup '
 	git checkout branch foo &&
 	test_tick &&
 	git commit -m "B" &&
-	git tag B
+	git tag B &&
+	test_tick &&
+	git checkout -b emptymerge A &&
+	git merge --no-ff -s ours master branch &&
+	test_tick &&
+	git checkout -b empty A &&
+	git commit --allow-empty -m empty
 '
 
 test_expect_success '--cherry-pick foo comes up empty' '

@@ -54,4 +60,10 @@ test_expect_success '--cherry-pick with independent, but identical branches' '
 		HEAD...master -- foo)"
 '
 
+# don't kick out commits c1, c2 with diff c1 c1^ == diff c2 c2^ but 
+# with different combined diffs
+test_expect_failure '--cherry-pick with a superseding merge and an empty commit' '
+	test "4" == "$(git rev-list --cherry-pick empty...emptymerge | wc -l)"
+'
+
 test_done

1.5.4