# [PATCH] rebase -p: Preserve fast-forwardable merges 4 messages from 2010-01-23 to 2010-01-26. Participants: Alex Scarborough, Johannes Schindelin. Thread: https://gitlist.dev/t/22351 ## Alex Scarborough, 2010-01-23 07:29 Subject: [PATCH] rebase -p: Preserve fast-forwardable merges Message-ID: URL: https://gitlist.dev/e/dd10f5481001222329i58e7b709m2c547c74161b6771%40mail.gmail.com ``` 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 --- 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 ``` ## Johannes Schindelin, 2010-01-25 14:10 Subject: Re: [PATCH] rebase -p: Preserve fast-forwardable merges Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.1001251508400.8733%40intel-tinevez-2-302 In-Reply-To: ``` 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 ``` ## Alex Scarborough, 2010-01-25 18:53 Subject: Re: [PATCH] rebase -p: Preserve fast-forwardable merges Message-ID: URL: https://gitlist.dev/e/dd10f5481001251053x2ac9fa62r57a46f1231e36560%40mail.gmail.com In-Reply-To: ``` 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 ``` ## Johannes Schindelin, 2010-01-26 11:14 Subject: Re: [PATCH] rebase -p: Preserve fast-forwardable merges Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.1001261214190.4641%40intel-tinevez-2-302 In-Reply-To: ``` 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 ```