{"thread":{"id":"23038","subject":"[PATCH] Teach --no-ff option to 'rebase -i'.","startedAt":"2010-03-16T16:08:55Z","lastAt":"2010-03-24T21:45:33Z","messageCount":32,"participants":["Marc Branchaud","Jonathan Nieder","Johannes Sixt","Peter Baumann","Avery Pennarun","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"136962","messageId":"1268755735-20588-1-git-send-email-marcnarc@xiplink.com","threadId":"23038","inReplyTo":null,"subject":"[PATCH] Teach --no-ff option to 'rebase -i'.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2010-03-16T16:08:55Z","receivedAt":"2010-03-16T16:08:55Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"This option tells rebase--interactive to cherry-pick all the commits in the\nrebased branch, instead of fast-forwarding over any unchanged commits.\n\nSigned-off-by: Marc Branchaud \n---\n\nThis offers an alterntive way to deal with reverted merges (the\nrevert-a-faulty-merge.txt howto recommends reverting the initial reversion\nbefore re-merging a modified topic branch).\n\nWith this change, you can instead use the --no-ff option to recreate the\nbranch with entirely new commits (they're new because at the very least the\ncommitter time is different). This obviates the need to revert the\nreversion, as you can re-merge the new topic branch directly.\n\n(Honestly, I wouldn't say that this approach is vastly superior to\nreverting the reversion. I just find it a little less messy and a little\nmore intuitive. It's also a bit easier to explain to people to \"use --no-ff\nafter reverting a merge\" instead of making sure they get the double-\nreversion right.)\n\n\t\tM.\n\n Documentation/git-rebase.txt | 13 ++++++++++++-\n git-rebase--interactive.sh | 10 ++++++++--\n t/t3417-rebase-no-ff.sh | 36 ++++++++++++++++++++++++++++++++++++\n 3 files changed, 56 insertions(+), 3 deletions(-)\n create mode 100755 t/t3417-rebase-no-ff.sh\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 823f2a4..01f1476 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -316,7 +316,18 @@ which makes little sense.\n \tcommit to be modified, and change the action of the moved\n \tcommit from `pick` to `squash` (or `fixup`).\n +\n-This option is only valid when '--interactive' option is used.\n+This option is only valid when the '--interactive' option is used.\n+\n+--no-ff::\n+\tCherry-pick all rebased commits instead of fast-forwarding over\n+\tthe unchanged ones. This ensures that the entire history of the\n+\trebased branch is composed of new commits. You may find this\n+\thelpful after reverting a topic branch merge, as this option\n+\trecreates the topic branch with fresh commits so it can be remerged\n+\tsuccessfully without needing to \"reverting the reversion\" (as described\n+\tin the link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To]).\n++\n+This option is only valid when the '--interactive' option is used.\n \n include::merge-strategies.txt[]\n \ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 3e4fd14..aecac3e 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -20,6 +20,7 @@ v,verbose display a diffstat of what changed upstream\n onto= rebase onto given branch instead of upstream\n p,preserve-merges try to recreate merges instead of ignoring them\n s,strategy= use the given merge strategy\n+no-ff never fast-forward any commits, even if they're unchanged\n m,merge always used (no-op)\n i,interactive always used (no-op)\n Actions:\n@@ -103,6 +104,7 @@ VERBOSE=\n OK_TO_SKIP_PRE_REBASE=\n REBASE_ROOT=\n AUTOSQUASH=\n+NO_SKIP=\n \n GIT_CHERRY_PICK_HELP=\" After resolving the conflicts,\n mark the corrected paths with 'git add ', and\n@@ -222,7 +224,7 @@ do_with_author () {\n }\n \n pick_one () {\n-\tno_ff=\n+\tno_ff=$NO_SKIP\n \tcase \"$1\" in -n) sha1=$2; no_ff=t ;; *) sha1=$1 ;; esac\n \toutput git rev-parse --verify $sha1 || die \"Invalid commit name: $sha1\"\n \ttest -d \"$REWRITTEN\" &&\n@@ -742,6 +744,10 @@ first and then run 'git rebase --continue' again.\"\n \t-i)\n \t\t# yeah, we know\n \t\t;;\n+\t--no-ff)\n+\t\t# Set -n parameter to pass to pick_one function\n+\t\tNO_SKIP=t\n+\t\t;;\n \t--root)\n \t\tREBASE_ROOT=t\n \t\t;;\n@@ -927,7 +933,7 @@ EOF\n \t\thas_action \"$TODO\" ||\n \t\t\tdie_abort \"Nothing to do\"\n \n-\t\ttest -d \"$REWRITTEN\" || skip_unnecessary_picks\n+\t\ttest -d \"$REWRITTEN\" || ( test -z \"$NO_SKIP\" && skip_unnecessary_picks )\n \n \t\tgit update-ref ORIG_HEAD $HEAD\n \t\toutput git checkout $ONTO && do_rest\ndiff --git a/t/t3417-rebase-no-ff.sh b/t/t3417-rebase-no-ff.sh\nnew file mode 100755\nindex 0000000..29455da\n--- /dev/null\n+++ b/t/t3417-rebase-no-ff.sh\n@@ -0,0 +1,36 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2010 Marc Branchaud\n+#\n+\n+test_description='git rebase -i --no-ff tests'\n+\n+. ./test-lib.sh\n+\n+. \"$TEST_DIRECTORY\"/lib-rebase.sh\n+\n+set_fake_editor\n+\n+test_expect_success setup '\n+\techo hello > hello &&\n+\tgit add hello &&\n+\tgit commit -m \"hello\" &&\n+\n+\techo world >> hello &&\n+\tgit commit -a -m \"hello world\" &&\n+\n+\techo goodbye >> hello &&\n+\tgit commit -a -m \"goodbye\" &&\n+\n+\tgit tag old_head\n+\t'\n+# Pause to ensure that the cherry-picked commits have a different\n+# timestamp.\n+sleep 1\n+\n+test_expect_success rebase '\n+\tgit rebase -i --no-ff HEAD~2 &&\n+\ttest ! $(git rev-parse HEAD) = $(git rev-parse old_head)\n+\t'\n+\n+test_done\n-- \n1.7.0.2.dirty\n"},{"id":"136970","messageId":"4B9FD9C1.9060200@xiplink.com","threadId":"23038","inReplyTo":"1268755735-20588-1-git-send-email-marcnarc@xiplink.com","subject":"Re: [PATCH] Teach --no-ff option to 'rebase -i'.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2010-03-16T19:19:29Z","receivedAt":"2010-03-16T19:19:29Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Apologies -- this patch fails several rebase unit tests.\n\nBack to the drawing board...\n\n\t\tM.\n\n\nMarc Branchaud wrote:\n> This option tells rebase--interactive to cherry-pick all the commits in the\n> rebased branch, instead of fast-forwarding over any unchanged commits.\n> \n> Signed-off-by: Marc Branchaud \n> ---\n> \n> This offers an alterntive way to deal with reverted merges (the\n> revert-a-faulty-merge.txt howto recommends reverting the initial reversion\n> before re-merging a modified topic branch).\n> \n> With this change, you can instead use the --no-ff option to recreate the\n> branch with entirely new commits (they're new because at the very least the\n> committer time is different). This obviates the need to revert the\n> reversion, as you can re-merge the new topic branch directly.\n> \n> (Honestly, I wouldn't say that this approach is vastly superior to\n> reverting the reversion. I just find it a little less messy and a little\n> more intuitive. It's also a bit easier to explain to people to \"use --no-ff\n> after reverting a merge\" instead of making sure they get the double-\n> reversion right.)\n> \n> \t\tM.\n> \n> Documentation/git-rebase.txt | 13 ++++++++++++-\n> git-rebase--interactive.sh | 10 ++++++++--\n> t/t3417-rebase-no-ff.sh | 36 ++++++++++++++++++++++++++++++++++++\n> 3 files changed, 56 insertions(+), 3 deletions(-)\n> create mode 100755 t/t3417-rebase-no-ff.sh\n> \n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index 823f2a4..01f1476 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -316,7 +316,18 @@ which makes little sense.\n> \tcommit to be modified, and change the action of the moved\n> \tcommit from `pick` to `squash` (or `fixup`).\n> +\n> -This option is only valid when '--interactive' option is used.\n> +This option is only valid when the '--interactive' option is used.\n> +\n> +--no-ff::\n> +\tCherry-pick all rebased commits instead of fast-forwarding over\n> +\tthe unchanged ones. This ensures that the entire history of the\n> +\trebased branch is composed of new commits. You may find this\n> +\thelpful after reverting a topic branch merge, as this option\n> +\trecreates the topic branch with fresh commits so it can be remerged\n> +\tsuccessfully without needing to \"reverting the reversion\" (as described\n> +\tin the link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To]).\n> ++\n> +This option is only valid when the '--interactive' option is used.\n> \n> include::merge-strategies.txt[]\n> \n> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> index 3e4fd14..aecac3e 100755\n> --- a/git-rebase--interactive.sh\n> +++ b/git-rebase--interactive.sh\n> @@ -20,6 +20,7 @@ v,verbose display a diffstat of what changed upstream\n> onto= rebase onto given branch instead of upstream\n> p,preserve-merges try to recreate merges instead of ignoring them\n> s,strategy= use the given merge strategy\n> +no-ff never fast-forward any commits, even if they're unchanged\n> m,merge always used (no-op)\n> i,interactive always used (no-op)\n> Actions:\n> @@ -103,6 +104,7 @@ VERBOSE=\n> OK_TO_SKIP_PRE_REBASE=\n> REBASE_ROOT=\n> AUTOSQUASH=\n> +NO_SKIP=\n> \n> GIT_CHERRY_PICK_HELP=\" After resolving the conflicts,\n> mark the corrected paths with 'git add ', and\n> @@ -222,7 +224,7 @@ do_with_author () {\n> }\n> \n> pick_one () {\n> -\tno_ff=\n> +\tno_ff=$NO_SKIP\n> \tcase \"$1\" in -n) sha1=$2; no_ff=t ;; *) sha1=$1 ;; esac\n> \toutput git rev-parse --verify $sha1 || die \"Invalid commit name: $sha1\"\n> \ttest -d \"$REWRITTEN\" &&\n> @@ -742,6 +744,10 @@ first and then run 'git rebase --continue' again.\"\n> \t-i)\n> \t\t# yeah, we know\n> \t\t;;\n> +\t--no-ff)\n> +\t\t# Set -n parameter to pass to pick_one function\n> +\t\tNO_SKIP=t\n> +\t\t;;\n> \t--root)\n> \t\tREBASE_ROOT=t\n> \t\t;;\n> @@ -927,7 +933,7 @@ EOF\n> \t\thas_action \"$TODO\" ||\n> \t\t\tdie_abort \"Nothing to do\"\n> \n> -\t\ttest -d \"$REWRITTEN\" || skip_unnecessary_picks\n> +\t\ttest -d \"$REWRITTEN\" || ( test -z \"$NO_SKIP\" && skip_unnecessary_picks )\n> \n> \t\tgit update-ref ORIG_HEAD $HEAD\n> \t\toutput git checkout $ONTO && do_rest\n> diff --git a/t/t3417-rebase-no-ff.sh b/t/t3417-rebase-no-ff.sh\n> new file mode 100755\n> index 0000000..29455da\n> --- /dev/null\n> +++ b/t/t3417-rebase-no-ff.sh\n> @@ -0,0 +1,36 @@\n> +#!/bin/sh\n> +#\n> +# Copyright (c) 2010 Marc Branchaud\n> +#\n> +\n> +test_description='git rebase -i --no-ff tests'\n> +\n> +. ./test-lib.sh\n> +\n> +. \"$TEST_DIRECTORY\"/lib-rebase.sh\n> +\n> +set_fake_editor\n> +\n> +test_expect_success setup '\n> +\techo hello > hello &&\n> +\tgit add hello &&\n> +\tgit commit -m \"hello\" &&\n> +\n> +\techo world >> hello &&\n> +\tgit commit -a -m \"hello world\" &&\n> +\n> +\techo goodbye >> hello &&\n> +\tgit commit -a -m \"goodbye\" &&\n> +\n> +\tgit tag old_head\n> +\t'\n> +# Pause to ensure that the cherry-picked commits have a different\n> +# timestamp.\n> +sleep 1\n> +\n> +test_expect_success rebase '\n> +\tgit rebase -i --no-ff HEAD~2 &&\n> +\ttest ! $(git rev-parse HEAD) = $(git rev-parse old_head)\n> +\t'\n> +\n> +test_done\n"},{"id":"136971","messageId":"1268768556-32176-1-git-send-email-marcnarc@xiplink.com","threadId":"23038","inReplyTo":"1268755735-20588-1-git-send-email-marcnarc@xiplink.com","subject":"[PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2010-03-16T19:42:36Z","receivedAt":"2010-03-16T19:42:36Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"This option tells rebase--interactive to cherry-pick all the commits in the\nrebased branch, instead of fast-forwarding over any unchanged commits.\n\nSigned-off-by: Marc Branchaud \n---\n\nNow passes all rebase unit tests. I'll repeat my rationale from the v1\nposting:\n\nThis offers an alterntive way to deal with reverted merges (the\nrevert-a-faulty-merge.txt howto recommends reverting the initial reversion\nbefore re-merging a modified topic branch).\n\nWith this change, you can instead use the --no-ff option to recreate the\nbranch with entirely new commits (they're new because at the very least the\ncommitter time is different). This obviates the need to revert the\nreversion, as you can re-merge the new topic branch directly.\n\n(Honestly, I wouldn't say that this approach is vastly superior to\nreverting the reversion. I just find it a little less messy and a little\nmore intuitive. It's also a bit easier to explain to people to \"use --no-ff\nafter reverting a merge\" instead of making sure they get the double-\nreversion right.)\n\n\t\tM.\n\n Documentation/git-rebase.txt | 13 ++++++++++++-\n git-rebase--interactive.sh | 10 ++++++++--\n t/t3417-rebase-no-ff.sh | 36 ++++++++++++++++++++++++++++++++++++\n 3 files changed, 56 insertions(+), 3 deletions(-)\n create mode 100755 t/t3417-rebase-no-ff.sh\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 823f2a4..01f1476 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -316,7 +316,18 @@ which makes little sense.\n \tcommit to be modified, and change the action of the moved\n \tcommit from `pick` to `squash` (or `fixup`).\n +\n-This option is only valid when '--interactive' option is used.\n+This option is only valid when the '--interactive' option is used.\n+\n+--no-ff::\n+\tCherry-pick all rebased commits instead of fast-forwarding over\n+\tthe unchanged ones. This ensures that the entire history of the\n+\trebased branch is composed of new commits. You may find this\n+\thelpful after reverting a topic branch merge, as this option\n+\trecreates the topic branch with fresh commits so it can be remerged\n+\tsuccessfully without needing to \"reverting the reversion\" (as described\n+\tin the link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To]).\n++\n+This option is only valid when the '--interactive' option is used.\n \n include::merge-strategies.txt[]\n \ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 3e4fd14..35943c0 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -20,6 +20,7 @@ v,verbose display a diffstat of what changed upstream\n onto= rebase onto given branch instead of upstream\n p,preserve-merges try to recreate merges instead of ignoring them\n s,strategy= use the given merge strategy\n+no-ff never fast-forward any commits, even if they're unchanged\n m,merge always used (no-op)\n i,interactive always used (no-op)\n Actions:\n@@ -103,6 +104,7 @@ VERBOSE=\n OK_TO_SKIP_PRE_REBASE=\n REBASE_ROOT=\n AUTOSQUASH=\n+NO_SKIP=\n \n GIT_CHERRY_PICK_HELP=\" After resolving the conflicts,\n mark the corrected paths with 'git add ', and\n@@ -222,7 +224,7 @@ do_with_author () {\n }\n \n pick_one () {\n-\tno_ff=\n+\tno_ff=$NO_SKIP\n \tcase \"$1\" in -n) sha1=$2; no_ff=t ;; *) sha1=$1 ;; esac\n \toutput git rev-parse --verify $sha1 || die \"Invalid commit name: $sha1\"\n \ttest -d \"$REWRITTEN\" &&\n@@ -742,6 +744,10 @@ first and then run 'git rebase --continue' again.\"\n \t-i)\n \t\t# yeah, we know\n \t\t;;\n+\t--no-ff)\n+\t\t# Set -n parameter to pass to pick_one function\n+\t\tNO_SKIP=t\n+\t\t;;\n \t--root)\n \t\tREBASE_ROOT=t\n \t\t;;\n@@ -927,7 +933,7 @@ EOF\n \t\thas_action \"$TODO\" ||\n \t\t\tdie_abort \"Nothing to do\"\n \n-\t\ttest -d \"$REWRITTEN\" || skip_unnecessary_picks\n+\t\ttest -d \"$REWRITTEN\" || test -n \"$NO_SKIP\" || skip_unnecessary_picks\n \n \t\tgit update-ref ORIG_HEAD $HEAD\n \t\toutput git checkout $ONTO && do_rest\ndiff --git a/t/t3417-rebase-no-ff.sh b/t/t3417-rebase-no-ff.sh\nnew file mode 100755\nindex 0000000..2a2be81\n--- /dev/null\n+++ b/t/t3417-rebase-no-ff.sh\n@@ -0,0 +1,36 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2010 Marc Branchaud\n+#\n+\n+test_description='git rebase -i --no-ff tests'\n+\n+. ./test-lib.sh\n+\n+. \"$TEST_DIRECTORY\"/lib-rebase.sh\n+\n+set_fake_editor\n+\n+test_expect_success setup '\n+\techo hello > hello &&\n+\tgit add hello &&\n+\tgit commit -m \"hello\" &&\n+\n+\techo world >> hello &&\n+\tgit commit -a -m \"hello world\" &&\n+\n+\techo goodbye >> hello &&\n+\tgit commit -a -m \"goodbye\" &&\n+\n+\tgit tag old_head\n+\t'\n+# Pause to ensure that the cherry-picked commits have a different\n+# timestamp.\n+sleep 1\n+\n+test_expect_success 'rebase -i --no-ff' '\n+\tgit rebase -i --no-ff HEAD~2 &&\n+\ttest ! $(git rev-parse HEAD) = $(git rev-parse old_head)\n+\t'\n+\n+test_done\n-- \n1.7.0.2.1.g6d104.dirty\n"},{"id":"136974","messageId":"20100316214717.GA24880@progeny.tock","threadId":"23038","inReplyTo":"1268768556-32176-1-git-send-email-marcnarc@xiplink.com","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-16T21:47:17Z","receivedAt":"2010-03-16T21:47:17Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Marc,\n\nMarc Branchaud wrote:\n\n> This option tells rebase--interactive to cherry-pick all the commits in the\n> rebased branch, instead of fast-forwarding over any unchanged commits.\n> \n> Signed-off-by: Marc Branchaud \n[...]\n> This offers an alterntive way to deal with reverted merges (the\n> revert-a-faulty-merge.txt howto recommends reverting the initial reversion\n> before re-merging a modified topic branch).\n> \n> With this change, you can instead use the --no-ff option to recreate the\n> branch with entirely new commits (they're new because at the very least the\n> committer time is different). This obviates the need to revert the\n> reversion, as you can re-merge the new topic branch directly.\n\nI think this rationale should go in the commit message, for the sake of\nfuture readers studying the code you’ve changed.\n\nBut let me make sure I understand it.\n\nIf I am understanding properly, your idea is that this would be used on\na branch after “unmerging” it from master:\n\n B --- C --- D [topic]\n / \\\n A --- ... --- M ... --- U [master]\n\nHere M is a merge commit and U a commit reverting the change from M^\nto M.\n\nAs howto/revert-a-faulty-merge explains, this is an accident waiting to\nhappen: if you merge master into topic, then it will pull in the revert\nalong with the rest of the changes. Similarly, if you merge topic into\nmaster, it will be a no-op (“already up to date”).\n\nYour solution, to rewrite the branch, should address both of these\nproblems. The new history looks like this:\n\n B' --- C' --- D' [topic]\n /\n | B --- C --- D\n |/ \\\n A --- ... --- M ... --- U [master]\n\nWhat happens now if you merge topic into master (or master into topic)?\n\nGit will try to reconcile the changes from the two branches since when\nthey diverged. master gained the changes from the old topic branch and\nthen reverted them since it diverged from topic; since merge algorithm\nis a simple three-way merge, all that history is ignored and Git will\njust combine any new changes from master with the changes from topic.\nSuccess.\n\nSide note:\n\nAfter this maneuver, I would want to merge ‘master’ into ‘topic’ as\nsoon as possible. Why? Because there is still a failure mode possible\nafter this: if you merge any commits from the old topic into the new\none before then, you’re back in trouble. This could happen if some\ntopic2 that topic ends up needing is based on a point in master after M\nand before U.\n\nAfter merging master into topic, the _meaning_ of the history is much\nclearer: by making U an ancestor, we are saying that as far as this\nbranch is concerned, the state at the tip of the topic branch is to be\npreferred over the reverted state.\n\nThis suggests an alternative method to achieve your goal:\n\n git checkout master\n git revert -m 1 M;\t# (1)\n git checkout topic\n git merge master^;\t# (2)\n git merge -s ours master;\t# (3)\n\n1. Add a commit U removing the changes introduced by topic from master.\n\n2. Merge all changes from master before the revert into topic.\n\n3. Declare the changes from topic to supersede the master branch.\n This way, if topic is ever merged back to master, the changes will be\n reintroduced again.\n\nResulting history:\n\n B --- C --- D --- ... --- T^ --- T [topic]\n / \\ / /\n A --- ... --- M ... --- U^ --- U [master]\n\nYou can avoid the perhaps pointless commit T^ by using --no-commit in\nthe command (2). If not all changes from M..master are suitable for\nmerging into topic, you can use the same trick on a temporary side\nbranch:\n\n git checkout -b revert-topic M\n git revert -m 1 M\n git checkout topic\n git merge --no-commit revert-topic^\n git merge -s ours revert-topic\n git checkout master\n git merge revert-topic\n\nIf not all changes from topic..M are suitable for merging into topic,\nthen things are harder. I’d suggest making a special unrevert-topic\nbranch as above to keep in the wings until its time.\n\n> (Honestly, I wouldn't say that this approach is vastly superior to\n> reverting the reversion. I just find it a little less messy and a little\n> more intuitive. It's also a bit easier to explain to people to \"use --no-ff\n> after reverting a merge\" instead of making sure they get the double-\n> reversion right.)\n\nHope this helps clarify things.\n\nYour patch itself might still be a good idea. I think plain\n‘git rebase’ already has something like it, in the form of the\n--force-rebase option. I have used it before, though I don’t remember\nwhy.\n\nThanks for the food for thought,\nJonathan\n"},{"id":"136991","messageId":"4BA07DC7.9070502@viscovery.net","threadId":"23038","inReplyTo":"20100316214717.GA24880@progeny.tock","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-03-17T06:59:19Z","receivedAt":"2010-03-17T06:59:19Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Jonathan Nieder schrieb:\n> If I am understanding properly, your idea is that this would be used on\n> a branch after “unmerging” it from master:\n> \n> B --- C --- D [topic]\n> / \\\n> A --- ... --- M ... --- U [master]\n> \n> Here M is a merge commit and U a commit reverting the change from M^\n> to M.\n\nIf I were to re-merge topic into master a second time after this\nsituation, I would install a temporary graft that removes the second\nparent of M and repeat the merge. After the graft is removed, the history\nwould look like this:\n\n B --- C --- D --------------. [topic]\n / \\ \\\n A --- ... --- M ... --- U ... N [master]\n\nAre there any downsides? I don't know - I haven't thought it through.\n\n-- Hannes\n"},{"id":"137025","messageId":"4BA0FBC7.3080305@xiplink.com","threadId":"23038","inReplyTo":"20100316214717.GA24880@progeny.tock","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2010-03-17T15:56:55Z","receivedAt":"2010-03-17T15:56:55Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Jonathan Nieder wrote:\n> Hi Marc,\n> \n> Marc Branchaud wrote:\n> \n>> This option tells rebase--interactive to cherry-pick all the commits in the\n>> rebased branch, instead of fast-forwarding over any unchanged commits.\n>>\n>> Signed-off-by: Marc Branchaud \n> [...]\n>> This offers an alterntive way to deal with reverted merges (the\n>> revert-a-faulty-merge.txt howto recommends reverting the initial reversion\n>> before re-merging a modified topic branch).\n>>\n>> With this change, you can instead use the --no-ff option to recreate the\n>> branch with entirely new commits (they're new because at the very least the\n>> committer time is different). This obviates the need to revert the\n>> reversion, as you can re-merge the new topic branch directly.\n> \n> I think this rationale should go in the commit message, for the sake of\n> future readers studying the code you’ve changed.\n\nEasy to do, but how necessary? The rationale is already in the description\nof --no-ff in rebase's man page.\n\nThere's an extra aspect to my motivation that I failed to mention, which is\nthat I would like the topic branch to stay rooted at its original commit.\nThis is because in our workflow that original commit is a synchronization\npoint for several maintenance and \"next\"-style branches, and keeping the\ntopic rooted there makes it easy to merge into different branches.\n\n> But let me make sure I understand it.\n> \n> If I am understanding properly, your idea is that this would be used on\n> a branch after “unmerging” it from master:\n> \n> B --- C --- D [topic]\n> / \\\n> A --- ... --- M ... --- U [master]\n> \n> Here M is a merge commit and U a commit reverting the change from M^\n> to M.\n> \n> As howto/revert-a-faulty-merge explains, this is an accident waiting to\n> happen: if you merge master into topic, then it will pull in the revert\n> along with the rest of the changes. Similarly, if you merge topic into\n> master, it will be a no-op (“already up to date”).\n> \n> Your solution, to rewrite the branch, should address both of these\n> problems. The new history looks like this:\n> \n> B' --- C' --- D' [topic]\n> /\n> | B --- C --- D\n> |/ \\\n> A --- ... --- M ... --- U [master]\n> \n> What happens now if you merge topic into master (or master into topic)?\n> \n> Git will try to reconcile the changes from the two branches since when\n> they diverged. master gained the changes from the old topic branch and\n> then reverted them since it diverged from topic; since merge algorithm\n> is a simple three-way merge, all that history is ignored and Git will\n> just combine any new changes from master with the changes from topic.\n> Success.\n\nYup, you got it!\n\n> Side note:\n> \n> After this maneuver, I would want to merge ‘master’ into ‘topic’ as\n> soon as possible.\n\nWell, I wouldn't want to do that because it would make it impossible to merge\nthe topic into some other branch without also bringing in all of master.\n\n> Why? Because there is still a failure mode possible\n> after this: if you merge any commits from the old topic into the new\n> one before then, you’re back in trouble. This could happen if some\n> topic2 that topic ends up needing is based on a point in master after M\n> and before U.\n\nIf the re-cast topic1 doesn't rewrite those commits, then the merge will\nsimply succeed because the code is already identical in both branches.\n\nBut if topic1 does rewrite those commits then there'll be a conflict. IMO\nthat's correct, because with the merging of topic2 the code in master really\ndid diverge in a relevant way from what's in topic1, so that conflict should\nget resolved in the normal way.\n\n> After merging master into topic, the _meaning_ of the history is much\n> clearer: by making U an ancestor, we are saying that as far as this\n> branch is concerned, the state at the tip of the topic branch is to be\n> preferred over the reverted state.\n\nYes, but it also means that all the history of master since commit A is now\npart of the topic, which isn't acceptable to me.\n\n> This suggests an alternative method to achieve your goal:\n> \n> git checkout master\n> git revert -m 1 M;\t# (1)\n> git checkout topic\n> git merge master^;\t# (2)\n> git merge -s ours master;\t# (3)\n> \n> 1. Add a commit U removing the changes introduced by topic from master.\n> \n> 2. Merge all changes from master before the revert into topic.\n> \n> 3. Declare the changes from topic to supersede the master branch.\n> This way, if topic is ever merged back to master, the changes will be\n> reintroduced again.\n> \n> Resulting history:\n> \n> B --- C --- D --- ... --- T^ --- T [topic]\n> / \\ / /\n> A --- ... --- M ... --- U^ --- U [master]\n\nI understand how this achieves your goal but, aside from dragging all of\nmaster into the topic, this is way more complicated than recreating the topic\nor even doing the double-revert. By creating T with \"-s ours\" U becomes like\na surrogate ancestor of the topic -- it's there, but it doesn't share any\ngenetic material with the topic. I think that's a recipe for confusion to\nfuture explorers of the repo's history.\n\nBesides, I do expect at least one of the topic's original commits to actually\nbe different in the recast topic -- the original merge was reverted because\nthe topic was faulty in some way, so there needs to be a real change made\nsomewhere. If the topic could simply be fixed with an extra commit or two\nafter D then re-merged, there wouldn't be a need to revert the original merge\nin the first place.\n\n> You can avoid the perhaps pointless commit T^ by using --no-commit in\n> the command (2). If not all changes from M..master are suitable for\n> merging into topic, you can use the same trick on a temporary side\n> branch:\n> \n> git checkout -b revert-topic M\n> git revert -m 1 M\n> git checkout topic\n> git merge --no-commit revert-topic^\n> git merge -s ours revert-topic\n> git checkout master\n> git merge revert-topic\n> \n> If not all changes from topic..M are suitable for merging into topic,\n> then things are harder. I’d suggest making a special unrevert-topic\n> branch as above to keep in the wings until its time.\n\nThis still brings all of the master's A..M^ commits into the topic.\n\n>> (Honestly, I wouldn't say that this approach is vastly superior to\n>> reverting the reversion. I just find it a little less messy and a little\n>> more intuitive. It's also a bit easier to explain to people to \"use --no-ff\n>> after reverting a merge\" instead of making sure they get the double-\n>> reversion right.)\n> \n> Hope this helps clarify things.\n> \n> Your patch itself might still be a good idea. I think plain\n> ‘git rebase’ already has something like it, in the form of the\n> --force-rebase option. I have used it before, though I don’t remember\n> why.\n\nNo, the man page says --force-rebase does something else.\n\nThanks for the feedback!\n\n\t\tM.\n"},{"id":"137027","messageId":"20100317155842.GA2557@m62s10.vlinux.de","threadId":"23038","inReplyTo":"4BA07DC7.9070502@viscovery.net","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2010-03-17T15:58:42Z","receivedAt":"2010-03-17T15:58:42Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Wed, Mar 17, 2010 at 07:59:19AM +0100, Johannes Sixt wrote:\n> Jonathan Nieder schrieb:\n> > If I am understanding properly, your idea is that this would be used on\n> > a branch after “unmerging” it from master:\n> > \n> > B --- C --- D [topic]\n> > / \\\n> > A --- ... --- M ... --- U [master]\n> > \n> > Here M is a merge commit and U a commit reverting the change from M^\n> > to M.\n> \n> If I were to re-merge topic into master a second time after this\n> situation, I would install a temporary graft that removes the second\n> parent of M and repeat the merge. After the graft is removed, the history\n> would look like this:\n> \n> B --- C --- D --------------. [topic]\n> / \\ \\\n> A --- ... --- M ... --- U ... N [master]\n> \n> Are there any downsides? I don't know - I haven't thought it through.\n> \n\nMight be. If there is any branch starting anywhere in between M and U\nwhich also needs to merge [topic] will also cause you headaches :-)\n\n B --- C --- D --------------. [topic]\n / \\ \\\n A --- ... --- M ... --- U ... N [master]\n \\\n x --- y [side_branch wich needs to merge topic] \n\n--\nPeter\n"},{"id":"137028","messageId":"4BA0FD5B.5090408@xiplink.com","threadId":"23038","inReplyTo":"4BA07DC7.9070502@viscovery.net","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2010-03-17T16:03:39Z","receivedAt":"2010-03-17T16:03:39Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Johannes Sixt wrote:\n> Jonathan Nieder schrieb:\n>> If I am understanding properly, your idea is that this would be used on\n>> a branch after “unmerging” it from master:\n>>\n>> B --- C --- D [topic]\n>> / \\\n>> A --- ... --- M ... --- U [master]\n>>\n>> Here M is a merge commit and U a commit reverting the change from M^\n>> to M.\n> \n> If I were to re-merge topic into master a second time after this\n> situation, I would install a temporary graft that removes the second\n> parent of M and repeat the merge. After the graft is removed, the history\n> would look like this:\n> \n> B --- C --- D --------------. [topic]\n> / \\ \\\n> A --- ... --- M ... --- U ... N [master]\n> \n> Are there any downsides? I don't know - I haven't thought it through.\n\nI'm not sure I follow how to create that graft.\n\nBut the original point (which I hadn't made clear) is that at least one of\nthe topic's commits needs to change in some substantial way. So it's not\njust a straight re-merge but a new take on the topic.\n\nConsider that if the topic's first commit (B) needed to be rewritten then the\nrepaired topic would contain only new commits and it could be merged into\nmaster without reverting the first merge's reversion.\n\nWhat \"rebase -i --no-ff\" does is allow you to ensure that this will always be\nthe case, even if you don't actually need to change the topic's first commit.\n\n\t\tM.\n"},{"id":"137029","messageId":"4BA0FE59.7020303@viscovery.net","threadId":"23038","inReplyTo":"20100317155842.GA2557@m62s10.vlinux.de","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-03-17T16:07:53Z","receivedAt":"2010-03-17T16:07:53Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Peter Baumann schrieb:\n> On Wed, Mar 17, 2010 at 07:59:19AM +0100, Johannes Sixt wrote:\n>> If I were to re-merge topic into master a second time after this\n>> situation, I would install a temporary graft that removes the second\n>> parent of M and repeat the merge. After the graft is removed, the history\n>> would look like this:\n>>\n>> B --- C --- D --------------. [topic]\n>> / \\ \\\n>> A --- ... --- M ... --- U ... N [master]\n>>\n>> Are there any downsides? I don't know - I haven't thought it through.\n>>\n> \n> Might be. If there is any branch starting anywhere in between M and U\n> which also needs to merge [topic] will also cause you headaches :-)\n> \n> B --- C --- D --------------. [topic]\n> / \\ \\\n> A --- ... --- M ... --- U ... N [master]\n> \\\n> x --- y [side_branch wich needs to merge topic] \n\n?? I don't follow you. The side branch already contains the topic. What do\nyou want to merge?\n\n-- Hannes\n"},{"id":"137031","messageId":"4BA1010E.8030908@viscovery.net","threadId":"23038","inReplyTo":"4BA0FD5B.5090408@xiplink.com","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-03-17T16:19:26Z","receivedAt":"2010-03-17T16:19:26Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Marc Branchaud schrieb:\n> Johannes Sixt wrote:\n>> If I were to re-merge topic into master a second time after this\n>> situation, I would install a temporary graft that removes the second\n>> parent of M and repeat the merge. After the graft is removed, the history\n>> would look like this:\n>>\n>> B --- C --- D --------------. [topic]\n>> / \\ \\\n>> A --- ... --- M ... --- U ... N [master]\n>>\n>> Are there any downsides? I don't know - I haven't thought it through.\n> \n> I'm not sure I follow how to create that graft.\n\n $ echo $(git rev-parse M M^) >> .git/info/grafts\n\n> But the original point (which I hadn't made clear) is that at least one of\n> the topic's commits needs to change in some substantial way. So it's not\n> just a straight re-merge but a new take on the topic.\n> \n> Consider that if the topic's first commit (B) needed to be rewritten then the\n> repaired topic would contain only new commits and it could be merged into\n> master without reverting the first merge's reversion.\n\nYou don't need --ff nor --no-ff in this case.\n\n> What \"rebase -i --no-ff\" does is allow you to ensure that this will always be\n> the case, even if you don't actually need to change the topic's first commit.\n\nBut why do you base the reworked topic on A instead of U or later?\n\nOr why don't you just mark the first commit as r(eword) and just exit the\neditor; it would rewrite the commit and all subsequent ones will be\nrewritten as well. Never in my life would I have searched for a *option*\nthat achieves the goal. It is such a rare situation that we don't need an\noption, do we?\n\n-- Hannes\n"},{"id":"137042","messageId":"20100317175320.GA26124@progeny.tock","threadId":"23038","inReplyTo":"4BA0FBC7.3080305@xiplink.com","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-17T17:53:20Z","receivedAt":"2010-03-17T17:53:20Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Marc Branchaud wrote:\n\n> If the re-cast topic1 doesn't rewrite those commits, then the merge will\n> simply succeed because the code is already identical in both branches.\n> \n> But if topic1 does rewrite those commits then there'll be a conflict. IMO\n> that's correct, because with the merging of topic2 the code in master really\n> did diverge in a relevant way from what's in topic1, so that conflict should\n> get resolved in the normal way.\n\nSorry, I did not think it through all the way. Here is an example of\nwhat I meant by trouble. Suppose you have re-cast topic using\nrebase --no-ff:\n\n B' --- C' --- D' [topic]\n /\n | B --- C --- D F [topic2]\n |/ \\ /\n A --- ... --- M --- E ... --- U [master]\n\ntopic represents a new feature that was merged prematurely and then\nreverted, and topic2 represents some helpful new plumbing.\n(introduction of a few functions, maybe).\n\nTo take advantage of the changes from F, someone merges topic2 into\ntopic and builds on it:\n\n .. X --- Y [topic]\n / /\n B' --- C' --- D' F [topic2]\n / /\n A -- ... -- M --- E ... --- U [master]\n\nNow someone decides it is time to merge topic into master. The\nmerge-base for Y and U is E, and the result is a that the changes from\ntopic are reverted.\n\nWhat I had missed: it would be just as dangerous to simply merge topic2\ndirectly. Merging ‘master’ into ‘topic’ does nothing to prevent that.\n\nThe new advice: when using rebase --no-ff this way, be sure to rewrite\n_every_ branch that includes those commits but doesn’t include U.\n\nJonathan\n"},{"id":"137044","messageId":"4BA11B23.4090801@xiplink.com","threadId":"23038","inReplyTo":"4BA1010E.8030908@viscovery.net","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2010-03-17T18:10:43Z","receivedAt":"2010-03-17T18:10:43Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Johannes Sixt wrote:\n> Marc Branchaud schrieb:\n>> Johannes Sixt wrote:\n>>> If I were to re-merge topic into master a second time after this\n>>> situation, I would install a temporary graft that removes the second\n>>> parent of M and repeat the merge. After the graft is removed, the history\n>>> would look like this:\n>>>\n>>> B --- C --- D --------------. [topic]\n>>> / \\ \\\n>>> A --- ... --- M ... --- U ... N [master]\n>>>\n>>> Are there any downsides? I don't know - I haven't thought it through.\n>> I'm not sure I follow how to create that graft.\n> \n> $ echo $(git rev-parse M M^) >> .git/info/grafts\n> \n>> But the original point (which I hadn't made clear) is that at least one of\n>> the topic's commits needs to change in some substantial way. So it's not\n>> just a straight re-merge but a new take on the topic.\n>>\n>> Consider that if the topic's first commit (B) needed to be rewritten then the\n>> repaired topic would contain only new commits and it could be merged into\n>> master without reverting the first merge's reversion.\n> \n> You don't need --ff nor --no-ff in this case.\n> \n>> What \"rebase -i --no-ff\" does is allow you to ensure that this will always be\n>> the case, even if you don't actually need to change the topic's first commit.\n> \n> But why do you base the reworked topic on A instead of U or later?\n\nI want the topic based on A so that I can merge it into other branches that\nare also based on A.\n\n> Or why don't you just mark the first commit as r(eword) and just exit the\n> editor; it would rewrite the commit and all subsequent ones will be\n> rewritten as well.\n\nYes, that works just as well (at least until someone optimizes the reword\ncommand).\n\n> Never in my life would I have searched for a *option*\n> that achieves the goal. It is such a rare situation that we don't need an\n> option, do we?\n\nThat's a more fundamental question. I don't feel strongly either way. The\nmain advantage I see with having the option is that it codifies the process,\nwith documentation and a unit test to help make sure it doesn't break. So if\nnobody wants the new option, I would then like to add a unit test to ensure\nthat rebase's reword command doesn't get optimized (if such a test doesn't\nalready exist), and maybe also add a note to the revert-a-faulty-merge howto.\n\n\t\tM.\n"},{"id":"137045","messageId":"20100317181347.GA26376@progeny.tock","threadId":"23038","inReplyTo":"20100317175320.GA26124@progeny.tock","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-17T18:13:47Z","receivedAt":"2010-03-17T18:13:47Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi again,\n\nSorry to keep talking to myself here...\n\nJonathan Nieder wrote:\n\n> To take advantage of the changes from F, someone merges topic2 into\n> topic and builds on it:\n> \n> .. X --- Y [topic]\n> / /\n> B' --- C' --- D' F [topic2]\n> / /\n> A -- ... -- M --- E ... --- U [master]\n> \n> Now someone decides it is time to merge topic into master. The\n> merge-base for Y and U is E, and the result is a that the changes from\n> topic are reverted.\n\nAlmost certainly bad.\n\n> What I had missed: it would be just as dangerous to simply merge topic2\n> directly. Merging ‘master’ into ‘topic’ does nothing to prevent that.\n\nMight be bad, might not, depending on what topic2 is about.\n\n> The new advice: when using rebase --no-ff this way, be sure to rewrite\n> _every_ branch that includes those commits but doesn’t include U.\n\nOr rather: rewrite every branch that you want to make supersede U.\n\nSurprisingly tricky.\n\nI prefer the “revert the faulty revert” technique because it is more\ntransparent. If it is only possible to re-merge now because of\ndevelopments that occured in topic, a simple revert would create a\nnon-bisectable history, but Johannes’s trick (or the uglier method I\ndescribed before) should work.\n\n git checkout master\n : >> .git/info/grafts\n cp .git/info/grafts .git/info/saved-grafts\n echo $(git rev-parse M M^) >> .git/info/grafts\n git merge topic;\t# being sure to mention M in the commit message!\n mv .git/info/saved-grafts .git/info/grafts\n\nJonathan\n"},{"id":"137048","messageId":"20100317184210.GB2557@m62s10.vlinux.de","threadId":"23038","inReplyTo":"4BA0FE59.7020303@viscovery.net","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2010-03-17T18:42:10Z","receivedAt":"2010-03-17T18:42:10Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Wed, Mar 17, 2010 at 05:07:53PM +0100, Johannes Sixt wrote:\n> Peter Baumann schrieb:\n> > On Wed, Mar 17, 2010 at 07:59:19AM +0100, Johannes Sixt wrote:\n> >> If I were to re-merge topic into master a second time after this\n> >> situation, I would install a temporary graft that removes the second\n> >> parent of M and repeat the merge. After the graft is removed, the history\n> >> would look like this:\n> >>\n> >> B --- C --- D --------------. [topic]\n> >> / \\ \\\n> >> A --- ... --- M ... --- U ... N [master]\n> >>\n> >> Are there any downsides? I don't know - I haven't thought it through.\n> >>\n> > \n> > Might be. If there is any branch starting anywhere in between M and U\n> > which also needs to merge [topic] will also cause you headaches :-)\n> > \n> > B --- C --- D --------------. [topic]\n> > / \\ \\\n> > A --- ... --- M ... --- U ... N [master]\n> > \\\n> > x --- y [side_branch wich needs to merge topic] \n> \n> ?? I don't follow you. The side branch already contains the topic. What do\n> you want to merge?\n> \n\nWon't it loose the revert 'U' after merging side_branch back to master?\n\nAh. Looking at the picture more closely, I could answer myself and say it would\nonly cause a huge mergeconflict, won't it?.\n\n--\nPeter\n"},{"id":"137073","messageId":"4BA1D183.3050907@viscovery.net","threadId":"23038","inReplyTo":"20100317184210.GB2557@m62s10.vlinux.de","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-03-18T07:08:51Z","receivedAt":"2010-03-18T07:08:51Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Peter Baumann schrieb:\n> On Wed, Mar 17, 2010 at 05:07:53PM +0100, Johannes Sixt wrote:\n>> Peter Baumann schrieb:\n>>> On Wed, Mar 17, 2010 at 07:59:19AM +0100, Johannes Sixt wrote:\n>>>> If I were to re-merge topic into master a second time after this\n>>>> situation, I would install a temporary graft that removes the second\n>>>> parent of M and repeat the merge. After the graft is removed, the history\n>>>> would look like this:\n>>>>\n>>>> B --- C --- D --------------. [topic]\n>>>> / \\ \\\n>>>> A --- ... --- M ... --- U ... N [master]\n>>>>\n>>>> Are there any downsides? I don't know - I haven't thought it through.\n>>>>\n>>> Might be. If there is any branch starting anywhere in between M and U\n>>> which also needs to merge [topic] will also cause you headaches :-)\n>>>\n>>> B --- C --- D --------------. [topic]\n>>> / \\ \\\n>>> A --- ... --- M ... --- U ... N [master]\n>>> \\\n>>> x --- y [side_branch wich needs to merge topic] \n>> ?? I don't follow you. The side branch already contains the topic. What do\n>> you want to merge?\n>>\n> \n> Won't it loose the revert 'U' after merging side_branch back to master?\n> \n> Ah. Looking at the picture more closely, I could answer myself and say it would\n> only cause a huge mergeconflict, won't it?.\n\nNo. N and the merge-base of N and y are identical (wrt changes introduced\nby B,C,D). At least this part will not cause any conflicts.\n\n-- Hannes\n"},{"id":"137075","messageId":"20100318080331.GC2557@m62s10.vlinux.de","threadId":"23038","inReplyTo":"4BA1D183.3050907@viscovery.net","subject":"Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2010-03-18T08:03:31Z","receivedAt":"2010-03-18T08:03:31Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Thu, Mar 18, 2010 at 08:08:51AM +0100, Johannes Sixt wrote:\n> Peter Baumann schrieb:\n> > On Wed, Mar 17, 2010 at 05:07:53PM +0100, Johannes Sixt wrote:\n> >> Peter Baumann schrieb:\n> >>> On Wed, Mar 17, 2010 at 07:59:19AM +0100, Johannes Sixt wrote:\n> >>>> If I were to re-merge topic into master a second time after this\n> >>>> situation, I would install a temporary graft that removes the second\n> >>>> parent of M and repeat the merge. After the graft is removed, the history\n> >>>> would look like this:\n> >>>>\n> >>>> B --- C --- D --------------. [topic]\n> >>>> / \\ \\\n> >>>> A --- ... --- M ... --- U ... N [master]\n> >>>>\n> >>>> Are there any downsides? I don't know - I haven't thought it through.\n> >>>>\n> >>> Might be. If there is any branch starting anywhere in between M and U\n> >>> which also needs to merge [topic] will also cause you headaches :-)\n> >>>\n> >>> B --- C --- D --------------. [topic]\n> >>> / \\ \\\n> >>> A --- ... --- M ... --- U ... N [master]\n> >>> \\\n> >>> x --- y [side_branch wich needs to merge topic] \n> >> ?? I don't follow you. The side branch already contains the topic. What do\n> >> you want to merge?\n> >>\n> > \n> > Won't it loose the revert 'U' after merging side_branch back to master?\n> > \n> > Ah. Looking at the picture more closely, I could answer myself and say it would\n> > only cause a huge mergeconflict, won't it?.\n> \n> No. N and the merge-base of N and y are identical (wrt changes introduced\n> by B,C,D). At least this part will not cause any conflicts.\n> \n\nYou are right. How could I missed that.\n\nThanks for the clarification.\n\n--\nPeter\n"},{"id":"137576","messageId":"1269285942-17496-1-git-send-email-marcnarc@xiplink.com","threadId":"23038","inReplyTo":"4BA11B23.4090801@xiplink.com","subject":"[PATCH] Test that the 'rebase -i' \"reword\" command always cherry-picks a commit.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2010-03-22T19:25:42Z","receivedAt":"2010-03-22T19:25:42Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"In particular, \"reword\" should cherry-pick a reworded commit even if the\ncommit's message is unchanged.\n\nThis behaviour provides a way to deal with a situation that can arise when\na merge had to be reverted. Added an addendum to revert-a-faulty-merge.txt\ndescribing the situation and how to use \"reword\" to handle it.\n---\n\nIs this more acceptable than adding --no-ff to rebase--interactive?\n\nI wasn't sure how to integrate the new text into revert-a-faulty-merge.txt.\nI went with an addendum, but I'm open to other approaches.\n\n\t\tM.\n\n Documentation/howto/revert-a-faulty-merge.txt | 64 +++++++++++++++++++++++++\n t/t3417-rebase-reword-forces-cherry-pick.sh | 59 +++++++++++++++++++++++\n 2 files changed, 123 insertions(+), 0 deletions(-)\n create mode 100755 t/t3417-rebase-reword-forces-cherry-pick.sh\n\ndiff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt\nindex 3b4a390..892433d 100644\n--- a/Documentation/howto/revert-a-faulty-merge.txt\n+++ b/Documentation/howto/revert-a-faulty-merge.txt\n@@ -142,6 +142,8 @@ different resolution strategies:\n revert of a merge was rebuilt from scratch (i.e. rebasing and fixing,\n as you seem to have interpreted), then re-merging the result without\n doing anything else fancy would be the right thing to do.\n+ (See the ADDENDUM below for how to rebuild a branch from scratch\n+ without changing its original branching-off point.)\n \n However, there are things to keep in mind when reverting a merge (and\n reverting such a revert).\n@@ -177,3 +179,65 @@ the answer is: \"oops, I really shouldn't have merged it, because it wasn't\n ready yet, and I really need to undo _all_ of the merge\"). So then you\n really should revert the merge, but when you want to re-do the merge, you\n now need to do it by reverting the revert.\n+\n+ADDENDUM\n+\n+Sometimes you're in a situation like this\n+\n+ P---o---o---M---x---x---W---x\n+ \\ /\n+ A---B---C\n+\n+where you:\n+\n+ - Need to rewrite one of the commits on the A-B-C branch; and\n+\n+ - Want the rewritten A-B-C branch to still start at commit P (perhaps P\n+ is a branching-off point for yet another branch, and you want be able to\n+ merge A-B-C into both branches).\n+\n+The natural thing to do in this case is to checkout the A-B-C branch and use\n+\"rebase -i A\" to change commit B. However, this does not rewrite commit A,\n+and you end up with this:\n+\n+ P---o---o---M---x---x---W---x\n+ \\ /\n+ A---B---C <-- old branch\n+ \\\n+ B'---C' <-- rewritten branch\n+\n+To merge A-B'-C' into the mainline branch you would still have to first revert\n+commit W in order to pick up the changes in A, but then it's likely that the\n+changes in B' will conflict with the original B changes re-introduced by the\n+reversion of W.\n+\n+However, you could avoid these problems if you recreated the entire branch,\n+including commit A:\n+\n+ P---o---o---M---x---x---W---x\n+ |\\ /\n+ | A---B---C <-- old branch\n+ \\\n+ A'---B'---C' <-- entirely recreated branch\n+\n+Now you can merge A'-B'-C' into the mainline branch without worrying about\n+first reverting W.\n+\n+But if you don't actually need to change commit A, then you need some way to\n+recreate it as a new commit with the same changes in it. One way to do this\n+is to use the \"reword\" command in \"rebase -i\". If you:\n+\n+ - Checkout the A-B-C branch\n+\n+ - Run \"rebase -i P\" to rebase the entire branch\n+\n+ - \"reword\" commit A (the first commit in the rebase script)\n+\n+ - Make NO changes to commit A's message\n+\n+then you'll end up with a new branch A'-B'-C' with all-new commits (all the\n+SHA IDs will be different) but that has the same changes that were in the\n+original A-B-C branch.\n+\n+You can then modify commit B' as you like and merge the new A'-B''-C' branch\n+into the mainline branch without first reverting commit W.\ndiff --git a/t/t3417-rebase-reword-forces-cherry-pick.sh b/t/t3417-rebase-reword-forces-cherry-pick.sh\nnew file mode 100755\nindex 0000000..3e29f0f\n--- /dev/null\n+++ b/t/t3417-rebase-reword-forces-cherry-pick.sh\n@@ -0,0 +1,59 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2010 Marc Branchaud\n+#\n+\n+test_description='git rebase interactive \"reword\" always forces cherry-pick\n+\n+This test ensures that the \"reword\" command of \"git rebase -i\" cherry-picks\n+a reworded commit even if no changes are made to the commit message.\n+\n+This behaviour provides a way to deal with a situation that can arise when a\n+merge had to be reverted. For details, see the ADDENDUM in\n+Documentation/howto/revert-a-faulty-merge.txt.\n+'\n+\n+. ./test-lib.sh\n+\n+. \"$TEST_DIRECTORY\"/lib-rebase.sh\n+\n+set_fake_editor\n+\n+# A simple linear history.\n+test_expect_success 'setup' '\n+\ttest_commit A file1 &&\n+\ttest_commit B file1 &&\n+\ttest_commit C file1 &&\n+\ttest_commit D file1 &&\n+\tgit branch old-master HEAD\n+'\n+\n+# Ensure that the rebased commits get a different timestamp.\n+test_tick\n+\n+# Reword the first commit, but don't actually change the message\n+test_expect_success 'reword' '\n+\tFAKE_LINES=\"reword 1 2 3\" git rebase -i A\n+'\n+\n+# There should be no textual differences between the old and new branches.\n+# However:\n+# - Commit A should be completely unchanged.\n+# - Commits B, C and D should have different SHA IDs.\n+test_expect_success 'verify' '\n+\ttouch empty &&\n+\ttest ! $(git rev-parse ) = $(git rev-parse master) &&\n+\tgit diff old-master master > out &&\n+\ttest_cmp empty out &&\n+\ttest ! $(git rev-parse C) = $(git rev-parse master^) &&\n+\tgit diff old-master^ master^ > out &&\n+\ttest_cmp empty out &&\n+\ttest ! $(git rev-parse B) = $(git rev-parse master^^) &&\n+\tgit diff old-master^^ master^^ > out &&\n+\ttest_cmp empty out &&\n+\ttest $(git rev-parse A) = $(git rev-parse master^^^) &&\n+\tgit diff old-master^^^ master^^^ > out &&\n+\ttest_cmp empty out\n+'\n+\n+test_done\n-- \n1.7.0.3\n"},{"id":"137584","messageId":"32541b131003221323u1ed540bbi87d8d427cfcc421a@mail.gmail.com","threadId":"23038","inReplyTo":"1269285942-17496-1-git-send-email-marcnarc@xiplink.com","subject":"Re: [PATCH] Test that the 'rebase -i' \"reword\" command always cherry-picks a commit.","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-03-22T20:23:19Z","receivedAt":"2010-03-22T20:23:19Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Mar 22, 2010 at 3:25 PM, Marc Branchaud wrote:\n> +Sometimes you're in a situation like this\n> +\n> + P---o---o---M---x---x---W---x\n> +  \\         /\n> +   A---B---C\n> +\n> +where you:\n> +\n> + - Need to rewrite one of the commits on the A-B-C branch; and\n> +\n> + - Want the rewritten A-B-C branch to still start at commit P (perhaps P\n> +   is a branching-off point for yet another branch, and you want be able to\n> +   merge A-B-C into both branches).\n> +\n> +The natural thing to do in this case is to checkout the A-B-C branch and use\n> +\"rebase -i A\" to change commit B.  However, this does not rewrite commit A,\n> +and you end up with this:\n> +\n> + P---o---o---M---x---x---W---x\n> +  \\         /\n> +   A---B---C   <-- old branch\n> +   \\\n> +    B'---C'    <-- rewritten branch\n> +\n> +To merge A-B'-C' into the mainline branch you would still have to first revert\n> +commit W in order to pick up the changes in A, but then it's likely that the\n> +changes in B' will conflict with the original B changes re-introduced by the\n> +reversion of W.\n\nI think you need to clarify in the above text that W is a revert of M.\n I was very confused by this at first.\n\nOther than that, I'll leave it to others more opinionated than me to\ncomment on whether regenerating a commit just for the sake of\nregenerating it is actually desirable or not :)\n\nHave fun,\n\nAvery\n"},{"id":"137587","messageId":"7vd3yw84pd.fsf@alter.siamese.dyndns.org","threadId":"23038","inReplyTo":"1269285942-17496-1-git-send-email-marcnarc@xiplink.com","subject":"Re: [PATCH] Test that the 'rebase -i' \"reword\" command always cherry-picks a commit.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-22T20:46:38Z","receivedAt":"2010-03-22T20:46:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> In particular, \"reword\" should cherry-pick a reworded commit even if the\n> commit's message is unchanged.\n>\n> This behaviour provides a way to deal with a situation that can arise when\n> a merge had to be reverted. Added an addendum to revert-a-faulty-merge.txt\n> describing the situation and how to use \"reword\" to handle it.\n> ---\n>\n> Is this more acceptable than adding --no-ff to rebase--interactive?\n>\n> I wasn't sure how to integrate the new text into revert-a-faulty-merge.txt.\n> I went with an addendum, but I'm open to other approaches.\n\nThe addendum looked readable, but I am a bit puzzled. \"rebase -i --no-ff\"\nalready exists, and is probably a more natural way to do this than saying\n\"reword\" but not rewording anything, no?\n\nI would actually say \"rebase -f P\" would be even easier and clearer,\nespecially as...\n\n> ...\n> +However, you could avoid these problems if you recreated the entire branch,\n> +including commit A:\n> +\n> + P---o---o---M---x---x---W---x\n> + |\\ /\n> + | A---B---C <-- old branch\n> + \\\n> + A'---B'---C' <-- entirely recreated branch\n> +\n> +Now you can merge A'-B'-C' into the mainline branch without worrying about\n> +first reverting W.\n> +\n> +But if you don't actually need to change commit A, then you need some way to\n> +recreate it as a new commit with the same changes in it.\n\n... this part seems to talk about working around the tendency of 'rebase -i'\nto fast-forward.\n"},{"id":"137588","messageId":"4BA7E9F5.2000404@xiplink.com","threadId":"23038","inReplyTo":"32541b131003221323u1ed540bbi87d8d427cfcc421a@mail.gmail.com","subject":"Re: [PATCH] Test that the 'rebase -i' \"reword\" command always cherry-picks a commit.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2010-03-22T22:06:45Z","receivedAt":"2010-03-22T22:06:45Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Avery Pennarun wrote:\n> On Mon, Mar 22, 2010 at 3:25 PM, Marc Branchaud wrote:\n>> +Sometimes you're in a situation like this\n>> +\n>> + P---o---o---M---x---x---W---x\n>> + \\ /\n>> + A---B---C\n>> +\n>> +where you:\n>> +\n>> + - Need to rewrite one of the commits on the A-B-C branch; and\n>> +\n>> + - Want the rewritten A-B-C branch to still start at commit P (perhaps P\n>> + is a branching-off point for yet another branch, and you want be able to\n>> + merge A-B-C into both branches).\n>> +\n>> +The natural thing to do in this case is to checkout the A-B-C branch and use\n>> +\"rebase -i A\" to change commit B. However, this does not rewrite commit A,\n>> +and you end up with this:\n>> +\n>> + P---o---o---M---x---x---W---x\n>> + \\ /\n>> + A---B---C <-- old branch\n>> + \\\n>> + B'---C' <-- rewritten branch\n>> +\n>> +To merge A-B'-C' into the mainline branch you would still have to first revert\n>> +commit W in order to pick up the changes in A, but then it's likely that the\n>> +changes in B' will conflict with the original B changes re-introduced by the\n>> +reversion of W.\n> \n> I think you need to clarify in the above text that W is a revert of M.\n> I was very confused by this at first.\n\nSomeone who reads through the whole file will see that W is the reversion of\nM. It's probably good to repeat that in the addendum for readers who jump to\nthe addendum right away.\n\n> Other than that, I'll leave it to others more opinionated than me to\n> comment on whether regenerating a commit just for the sake of\n> regenerating it is actually desirable or not :)\n\nI'm all ears!\n\n\t\tM.\n"},{"id":"137589","messageId":"20100322220929.GA1384@progeny.tock","threadId":"23038","inReplyTo":"1269285942-17496-1-git-send-email-marcnarc@xiplink.com","subject":"Re: [PATCH] Test that the 'rebase -i' \"reword\" command always cherry-picks a commit.","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-22T22:09:29Z","receivedAt":"2010-03-22T22:09:29Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Marc Branchaud wrote:\n\n> Is this more acceptable than adding --no-ff to rebase--interactive?\n\nNo, in my opinion the latter is better, and I suspect it will go in. :)\n\nNo one has objected to the --no-ff option. I like it: if someone is\ntrying to reset the committer date on a collection of patches, I’d\nrather they use rebase -f or rebase -i --no-ff than format-patch and am.\nIt’s cooking in pu for the moment, and from here the natural progression\nis to next, master, then maybe maint.\n\nHope that helps,\nJonathan\n"},{"id":"137641","messageId":"4BA8D263.8040602@xiplink.com","threadId":"23038","inReplyTo":"7vd3yw84pd.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Test that the 'rebase -i' \"reword\" command always cherry-picks a commit.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2010-03-23T14:38:27Z","receivedAt":"2010-03-23T14:38:27Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Junio C Hamano wrote:\n> Marc Branchaud writes:\n> \n>> In particular, \"reword\" should cherry-pick a reworded commit even if the\n>> commit's message is unchanged.\n>>\n>> This behaviour provides a way to deal with a situation that can arise when\n>> a merge had to be reverted. Added an addendum to revert-a-faulty-merge.txt\n>> describing the situation and how to use \"reword\" to handle it.\n>> ---\n>>\n>> Is this more acceptable than adding --no-ff to rebase--interactive?\n>>\n>> I wasn't sure how to integrate the new text into revert-a-faulty-merge.txt.\n>> I went with an addendum, but I'm open to other approaches.\n> \n> The addendum looked readable, but I am a bit puzzled.\n\nYa think _you're_ puzzled? :)\n\n> \"rebase -i --no-ff\"\n> already exists, and is probably a more natural way to do this than saying\n> \"reword\" but not rewording anything, no?\n> \n> I would actually say \"rebase -f P\" would be even easier and clearer,\n> especially as...\n> \n>> ...\n>> +However, you could avoid these problems if you recreated the entire branch,\n>> +including commit A:\n>> +\n>> + P---o---o---M---x---x---W---x\n>> + |\\ /\n>> + | A---B---C <-- old branch\n>> + \\\n>> + A'---B'---C' <-- entirely recreated branch\n>> +\n>> +Now you can merge A'-B'-C' into the mainline branch without worrying about\n>> +first reverting W.\n>> +\n>> +But if you don't actually need to change commit A, then you need some way to\n>> +recreate it as a new commit with the same changes in it.\n> \n> ... this part seems to talk about working around the tendency of 'rebase -i'\n> to fast-forward.\n\nYes. Thanks for pointing this out, it's cleared up a lot for me.\n\nI was confused about the purpose of \"rebase -f\". Jonathan Nieder even\npointed me to it when I posted my original patch for \"rebase -i --no-ff\", but\nthe description in the man page threw me:\n\n\tForce the rebase even if the current branch is a descendant of\n\tthe commit you are rebasing onto. Normally the command will\n\texit with the message \"Current branch is up to date\" in such a\n\tsituation.\n\nI didn't realize that this is exactly the situation that \"rebase -i\" normally\ndeals with (-i basically implies -f), and that \"rebase -f\" would do exactly\nwhat I wanted \"rebase -i --no-ff\" to do.\n\nBut I think I see an approach that might make sense:\n\n - Teach \"rebase -i\" to recognize the -f parameter (instead of --no-ff).\n\n - Update rebase's man page to better explain -f.\n\n - Update revert-a-faulty-merge.txt to explain how to use \"rebase [-i] -f\".\n\nI'll submit a new patch shortly.\n\n\t\tM.\n"},{"id":"137647","messageId":"1269361187-31291-1-git-send-email-marcnarc@xiplink.com","threadId":"23038","inReplyTo":"4BA8D263.8040602@xiplink.com","subject":"[PATCHv3] Teach -f/--force-rebase option to 'rebase -i'.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2010-03-23T16:19:47Z","receivedAt":"2010-03-23T16:19:47Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"This option tells rebase--interactive to cherry-pick all the commits in the\nrebased branch, instead of fast-forwarding over any unchanged commits.\n\nAlso expanded -f's description in rebase's man page.\n\n-f offers an alterntive way to deal with reverted merges. Instead of\n\"reverting the revert\" you can use \"rebase -f [-i]\" to recreate the branch\nwith entirely new commits (they're new because at the very least the\ncommitter time is different). This obviates the need to revert the\nreversion, as you can re-merge the new topic branch directly. Added an\naddendum to revert-a-faulty-merge.txt describing the situation and how to\nuse -f to handle it.\n\nSigned-off-by: Marc Branchaud \n---\n\nIt seems more natural to me to just teach -f to \"rebase -i\" instead of adding\na new --no-ff option.\n\nThis patch combines my initial \"--no-ff\" patch with the documentation changes\nin my \"reword\" patch. I moved the unit test for \"rebase -f -i\" into\nt3404-rebase-interactive.sh.\n\n\t\tM.\n\n\n Documentation/git-rebase.txt | 10 ++++-\n Documentation/howto/revert-a-faulty-merge.txt | 57 +++++++++++++++++++++++++\n git-rebase--interactive.sh | 9 +++-\n t/t3404-rebase-interactive.sh | 36 ++++++++++++++--\n 4 files changed, 104 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 823f2a4..1fd8d1c 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -274,9 +274,15 @@ which makes little sense.\n -f::\n --force-rebase::\n \tForce the rebase even if the current branch is a descendant\n-\tof the commit you are rebasing onto. Normally the command will\n+\tof the commit you are rebasing onto. Normally non-interactive rebase will\n \texit with the message \"Current branch is up to date\" in such a\n-\tsituation.\n+\tsituation. With --interactive, this option forces rebase to\n+\tcherry-pick all commits, even if they're not actually changed.\n++\n+--force-rebase can sometimes be helpful after reverting a topic branch merge,\n+as it recreates the topic branch with fresh commits so it can be remerged\n+successfully without needing to \"revert the reversion\" (see the\n+link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To]).\n \n --ignore-whitespace::\n --whitespace=