problem with git rebase -i

problem with git rebase -i

[Uwe Kleine-König]

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

Re: problem with git rebase -i

[Uwe Kleine-König]

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.

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

Re: problem with git rebase -i

[Uwe Kleine-König]

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

[PATCH] new test: rev-list --cherry-pick excludes an empty commit against a superseding merge

[Uwe Kleine-König]

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.

Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
---
 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?

diff --git a/t/t6007-rev-list-cherry-pick-file.sh b/t/t6007-rev-list-cherry-pick-file.sh
index 4b8611c..26f62e1 100755
--- a/t/t6007-rev-list-cherry-pick-file.sh
+++ b/t/t6007-rev-list-cherry-pick-file.sh
@@ -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