{"thread":{"id":"22351","subject":"[PATCH] rebase -p: Preserve fast-forwardable merges","startedAt":"2010-01-23T07:29:26Z","lastAt":"2010-01-26T11:14:40Z","messageCount":4,"participants":["Alex Scarborough","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"132455","messageId":"dd10f5481001222329i58e7b709m2c547c74161b6771@mail.gmail.com","threadId":"22351","inReplyTo":null,"subject":"[PATCH] rebase -p: Preserve fast-forwardable merges","fromName":"Alex Scarborough","fromEmail":"alex@gameclay.com","sentAt":"2010-01-23T07:29:26Z","receivedAt":"2010-01-23T07:29:26Z","isPatch":true,"sender":{"key":"alex@gameclay.com","avatar":null},"body":"Previously, rebase -p would not preserve a merge commit if the merge\ncould be resolved as a fast-forward.  rebase -p now passes --no-ff to\ngit merge when recreating a merge commit, which ensures that merge\ncommits created with git merge --no-ff are preserved.\n\nSigned-off-by: Alex Scarborough <alex@gameclay.com>\n---\nFirst patch, so here's hoping neither I nor my mail client messed up\ntoo much.\n\nThis patch will not apply cleanly to branches which do not have\nmh/rebase-fixup merged in, as that series removed the wrap of the\nline I changed.\n\n git-rebase--interactive.sh                         |    2 +-\n t/t3416-rebase-preserve-fast-forwardable-merges.sh |   41 ++++++++++++++++++++\n 2 files changed, 42 insertions(+), 1 deletions(-)\n create mode 100755 t/t3416-rebase-preserve-fast-forwardable-merges.sh\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex c2f6089..a7a2acc 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -343,7 +343,7 @@ pick_one_preserving_merges () {\n \t\t\t# No point in merging the first parent, that's HEAD\n \t\t\tnew_parents=${new_parents# $first_parent}\n \t\t\tif ! do_with_author output \\\n-\t\t\t\tgit merge $STRATEGY -m \"$msg\" $new_parents\n+\t\t\t\tgit merge --no-ff $STRATEGY -m \"$msg\" $new_parents\n \t\t\tthen\n \t\t\t\tprintf \"%s\\n\" \"$msg\" > \"$GIT_DIR\"/MERGE_MSG\n \t\t\t\tdie_with_patch $sha1 \"Error redoing merge $sha1\"\ndiff --git a/t/t3416-rebase-preserve-fast-forwardable-merges.sh\nb/t/t3416-rebase-preserve-fast-forwardable-merges.sh\nnew file mode 100755\nindex 0000000..d46bf91\n--- /dev/null\n+++ b/t/t3416-rebase-preserve-fast-forwardable-merges.sh\n@@ -0,0 +1,41 @@\n+#!/bin/sh\n+\n+test_description='git rebase preserve fastforwardable merges\n+\n+This test runs git rebase with -p and checks that merges created by\n+git merge --no-ff are properly carried along.\n+'\n+. ./test-lib.sh\n+\n+# set up three branches like this:\n+#\n+# A1 - C1 - - - E1\n+#   \\   \\       /\n+#    \\   -- D1 --\n+#     \\\n+#      -- B1\n+\n+test_expect_success 'setup' '\n+\ttest_commit A1 &&\n+\ttest_commit B1 &&\n+\tgit reset --hard A1 &&\n+\ttest_commit C1 &&\n+\ttest_commit D1 &&\n+\tgit reset --hard C1 &&\n+\ttest_tick &&\n+\tgit merge --no-ff -m \"E1\" \"D1\" &&\n+\tgit tag \"E1\"\n+'\n+\n+# Should result in:\n+#\n+# A1 - B1 - C2 - - - E2\n+#            \\       /\n+#             -- D2 --\n+#\n+test_expect_success 'rebase C1 onto B1' '\n+\tgit rebase -p B1 &&\n+\tgit rev-parse HEAD^2\n+'\n+\n+test_done\n-- \n1.6.6\n"},{"id":"132605","messageId":"alpine.DEB.1.00.1001251508400.8733@intel-tinevez-2-302","threadId":"22351","inReplyTo":"dd10f5481001222329i58e7b709m2c547c74161b6771@mail.gmail.com","subject":"Re: [PATCH] rebase -p: Preserve fast-forwardable merges","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-01-25T14:10:21Z","receivedAt":"2010-01-25T14:10:21Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 22 Jan 2010, Alex Scarborough wrote:\n\n> Previously, rebase -p would not preserve a merge commit if the merge\n> could be resolved as a fast-forward.  rebase -p now passes --no-ff to\n> git merge when recreating a merge commit, which ensures that merge\n> commits created with git merge --no-ff are preserved.\n\nFor my use case (well, it used to be my use case), namely keeping a number \nof topic branches on top of an upstream up-to-date, this is not the \ndesired action.  In my use case, merged topic branches should just vanish, \nand not even leave a merge commit.\n\n> First patch, so here's hoping neither I nor my mail client messed up\n> too much.\n\nI think you did real fine, even providing a test case, which not many \nsubmitters do!\n\nCiao,\nDscho\n"},{"id":"132618","messageId":"dd10f5481001251053x2ac9fa62r57a46f1231e36560@mail.gmail.com","threadId":"22351","inReplyTo":"alpine.DEB.1.00.1001251508400.8733@intel-tinevez-2-302","subject":"Re: [PATCH] rebase -p: Preserve fast-forwardable merges","fromName":"Alex Scarborough","fromEmail":"alex@gameclay.com","sentAt":"2010-01-25T18:53:06Z","receivedAt":"2010-01-25T18:53:06Z","isPatch":true,"sender":{"key":"alex@gameclay.com","avatar":null},"body":"On Mon, Jan 25, 2010, Johannes Schindelin wrote:\n> On Fri, 22 Jan 2010, Alex Scarborough wrote:\n>\n> > Previously, rebase -p would not preserve a merge commit if the merge\n> > could be resolved as a fast-forward.  rebase -p now passes --no-ff to\n> > git merge when recreating a merge commit, which ensures that merge\n> > commits created with git merge --no-ff are preserved.\n>\n> For my use case (well, it used to be my use case), namely keeping a number\n> of topic branches on top of an upstream up-to-date, this is not the\n> desired action.  In my use case, merged topic branches should just vanish,\n> and not even leave a merge commit.\n\nI see.  In that use case this patch would be rather irritating :)\n\nWhat do you think of adding a --no-ff option to git rebase which, when used\nwith -p, will recreate merge commits even if they could be resolved as a\nfast-forward?  That would leave your use case unchanged while giving my\nuse case a way out, so to speak.\n\nEither way, I suggest we change the documentation for rebase -p to state\nthat it does not preserve merge commits that can be fast-forwarded after\nrebasing.\n\nIf it sounds good, I should be able to roll some patches by the end of the\nweek.\n\n-Alex Scarborough\n"},{"id":"132669","messageId":"alpine.DEB.1.00.1001261214190.4641@intel-tinevez-2-302","threadId":"22351","inReplyTo":"dd10f5481001251053x2ac9fa62r57a46f1231e36560@mail.gmail.com","subject":"Re: [PATCH] rebase -p: Preserve fast-forwardable merges","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-01-26T11:14:40Z","receivedAt":"2010-01-26T11:14:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 25 Jan 2010, Alex Scarborough wrote:\n\n> On Mon, Jan 25, 2010, Johannes Schindelin wrote:\n> > On Fri, 22 Jan 2010, Alex Scarborough wrote:\n> >\n> > > Previously, rebase -p would not preserve a merge commit if the merge \n> > > could be resolved as a fast-forward.  rebase -p now passes --no-ff \n> > > to git merge when recreating a merge commit, which ensures that \n> > > merge commits created with git merge --no-ff are preserved.\n> >\n> > For my use case (well, it used to be my use case), namely keeping a \n> > number of topic branches on top of an upstream up-to-date, this is not \n> > the desired action.  In my use case, merged topic branches should just \n> > vanish, and not even leave a merge commit.\n> \n> I see.  In that use case this patch would be rather irritating :)\n> \n> What do you think of adding a --no-ff option to git rebase which, when \n> used with -p, will recreate merge commits even if they could be resolved \n> as a fast-forward?  That would leave your use case unchanged while \n> giving my use case a way out, so to speak.\n\nThat would make most sense, I agree.\n\nThanks,\nDscho"}]}