All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] rebase -p: Preserve fast-forwardable merges
@ 2010-01-23  7:29 Alex Scarborough
  2010-01-25 14:10 ` Johannes Schindelin
  0 siblings, 1 reply; 4+ messages in thread
From: Alex Scarborough @ 2010-01-23  7:29 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Johannes Schindelin, Michael Haggerty, Alex Scarborough

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 <alex@gameclay.com>
---
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

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] rebase -p: Preserve fast-forwardable merges
  2010-01-23  7:29 [PATCH] rebase -p: Preserve fast-forwardable merges Alex Scarborough
@ 2010-01-25 14:10 ` Johannes Schindelin
  2010-01-25 18:53   ` Alex Scarborough
  0 siblings, 1 reply; 4+ messages in thread
From: Johannes Schindelin @ 2010-01-25 14:10 UTC (permalink / raw)
  To: Alex Scarborough; +Cc: git, Junio C Hamano, Michael Haggerty

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] rebase -p: Preserve fast-forwardable merges
  2010-01-25 14:10 ` Johannes Schindelin
@ 2010-01-25 18:53   ` Alex Scarborough
  2010-01-26 11:14     ` Johannes Schindelin
  0 siblings, 1 reply; 4+ messages in thread
From: Alex Scarborough @ 2010-01-25 18:53 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: git, Junio C Hamano, Michael Haggerty, Alex Scarborough

On Mon, Jan 25, 2010, Johannes Schindelin wrote:
> 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.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] rebase -p: Preserve fast-forwardable merges
  2010-01-25 18:53   ` Alex Scarborough
@ 2010-01-26 11:14     ` Johannes Schindelin
  0 siblings, 0 replies; 4+ messages in thread
From: Johannes Schindelin @ 2010-01-26 11:14 UTC (permalink / raw)
  To: Alex Scarborough; +Cc: git, Junio C Hamano, Michael Haggerty

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1111 bytes --]

Hi,

On Mon, 25 Jan 2010, Alex Scarborough wrote:

> On Mon, Jan 25, 2010, Johannes Schindelin wrote:
> > 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.
> 
> 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-01-26 11:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-23  7:29 [PATCH] rebase -p: Preserve fast-forwardable merges Alex Scarborough
2010-01-25 14:10 ` Johannes Schindelin
2010-01-25 18:53   ` Alex Scarborough
2010-01-26 11:14     ` Johannes Schindelin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.