[PATCH] rebase -p: Preserve fast-forwardable merges

Previously, rebase -p would not preserve a merge commit if the merge
could be resolved as a fast-forward.  rebase -p now passes --no-ff to
git merge when recreating a merge commit, which ensures that merge
commits created with git merge --no-ff are preserved.

Signed-off-by: Alex Scarborough <redacted>
---
First patch, so here's hoping neither I nor my mail client messed up
too much.

This patch will not apply cleanly to branches which do not have
mh/rebase-fixup merged in, as that series removed the wrap of the
line I changed.

 git-rebase--interactive.sh                         |    2 +-
 t/t3416-rebase-preserve-fast-forwardable-merges.sh |   41 ++++++++++++++++++++
 2 files changed, 42 insertions(+), 1 deletions(-)
 create mode 100755 t/t3416-rebase-preserve-fast-forwardable-merges.sh

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c2f6089..a7a2acc 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh

@@ -343,7 +343,7 @@ pick_one_preserving_merges () {
 			# No point in merging the first parent, that's HEAD
 			new_parents=${new_parents# $first_parent}
 			if ! do_with_author output \
-				git merge $STRATEGY -m "$msg" $new_parents
+				git merge --no-ff $STRATEGY -m "$msg" $new_parents
 			then
 				printf "%s\n" "$msg" > "$GIT_DIR"/MERGE_MSG
 				die_with_patch $sha1 "Error redoing merge $sha1"

diff --git a/t/t3416-rebase-preserve-fast-forwardable-merges.sh

b/t/t3416-rebase-preserve-fast-forwardable-merges.sh
new file mode 100755
index 0000000..d46bf91

--- /dev/null
+++ b/t/t3416-rebase-preserve-fast-forwardable-merges.sh

@@ -0,0 +1,41 @@
+#!/bin/sh
+
+test_description='git rebase preserve fastforwardable merges
+
+This test runs git rebase with -p and checks that merges created by
+git merge --no-ff are properly carried along.
+'
+. ./test-lib.sh
+
+# set up three branches like this:
+#
+# A1 - C1 - - - E1
+#   \   \       /
+#    \   -- D1 --
+#     \
+#      -- B1
+
+test_expect_success 'setup' '
+	test_commit A1 &&
+	test_commit B1 &&
+	git reset --hard A1 &&
+	test_commit C1 &&
+	test_commit D1 &&
+	git reset --hard C1 &&
+	test_tick &&
+	git merge --no-ff -m "E1" "D1" &&
+	git tag "E1"
+'
+
+# Should result in:
+#
+# A1 - B1 - C2 - - - E2
+#            \       /
+#             -- D2 --
+#
+test_expect_success 'rebase C1 onto B1' '
+	git rebase -p B1 &&
+	git rev-parse HEAD^2
+'
+
+test_done

-- 
1.6.6

Hi,

On Fri, 22 Jan 2010, Alex Scarborough wrote:

Previously, rebase -p would not preserve a merge commit if the merge
could be resolved as a fast-forward.  rebase -p now passes --no-ff to
git merge when recreating a merge commit, which ensures that merge
commits created with git merge --no-ff are preserved.

For my use case (well, it used to be my use case), namely keeping a number 
of topic branches on top of an upstream up-to-date, this is not the 
desired action.  In my use case, merged topic branches should just vanish, 
and not even leave a merge commit.

First patch, so here's hoping neither I nor my mail client messed up
too much.

I think you did real fine, even providing a test case, which not many 
submitters do!

Ciao,
Dscho

On Mon, Jan 25, 2010, Johannes Schindelin wrote:

On Fri, 22 Jan 2010, Alex Scarborough wrote:

quoted

Previously, rebase -p would not preserve a merge commit if the merge
could be resolved as a fast-forward.  rebase -p now passes --no-ff to
git merge when recreating a merge commit, which ensures that merge
commits created with git merge --no-ff are preserved.

For my use case (well, it used to be my use case), namely keeping a number
of topic branches on top of an upstream up-to-date, this is not the
desired action.  In my use case, merged topic branches should just vanish,
and not even leave a merge commit.

I see.  In that use case this patch would be rather irritating :)

What do you think of adding a --no-ff option to git rebase which, when used
with -p, will recreate merge commits even if they could be resolved as a
fast-forward?  That would leave your use case unchanged while giving my
use case a way out, so to speak.

Either way, I suggest we change the documentation for rebase -p to state
that it does not preserve merge commits that can be fast-forwarded after
rebasing.

If it sounds good, I should be able to roll some patches by the end of the
week.

-Alex Scarborough

Hi,

On Mon, 25 Jan 2010, Alex Scarborough wrote:

On Mon, Jan 25, 2010, Johannes Schindelin wrote:

quoted

On Fri, 22 Jan 2010, Alex Scarborough wrote:

quoted

Previously, rebase -p would not preserve a merge commit if the merge 
could be resolved as a fast-forward.  rebase -p now passes --no-ff 
to git merge when recreating a merge commit, which ensures that 
merge commits created with git merge --no-ff are preserved.

For my use case (well, it used to be my use case), namely keeping a 
number of topic branches on top of an upstream up-to-date, this is not 
the desired action.  In my use case, merged topic branches should just 
vanish, and not even leave a merge commit.

I see.  In that use case this patch would be rather irritating :)

What do you think of adding a --no-ff option to git rebase which, when 
used with -p, will recreate merge commits even if they could be resolved 
as a fast-forward?  That would leave your use case unchanged while 
giving my use case a way out, so to speak.

That would make most sense, I agree.

Thanks,
Dscho