Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.kernel.org/pub/scm/git/git.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJunio C Hamano <gitster@pobox.com>2010-04-03 23:28:44 +0400
committerJunio C Hamano <gitster@pobox.com>2010-04-03 23:28:44 +0400
commit9234b003726556e0d3d0ea8ade97dc9f7bd50a6e (patch)
tree194e8895d8a2e7c7dba0f5e6ab9108231aaae711 /Documentation
parent7b1cb5c40ebb57c5a26f1335807be24dba8d4518 (diff)
parentb499549401cb2b1f6c30d09681380fd519938eb0 (diff)
Merge branch 'mb/rebase-i-no-ff'
* mb/rebase-i-no-ff: Teach rebase the --no-ff option. Conflicts: git-rebase--interactive.sh t/t3404-rebase-interactive.sh
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/git-rebase.txt23
-rw-r--r--Documentation/howto/revert-a-faulty-merge.txt90
2 files changed, 111 insertions, 2 deletions
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 823f2a4638..0d07b1b207 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -274,9 +274,16 @@ which makes little sense.
-f::
--force-rebase::
Force the rebase even if the current branch is a descendant
- of the commit you are rebasing onto. Normally the command will
+ of the commit you are rebasing onto. Normally non-interactive rebase will
exit with the message "Current branch is up to date" in such a
situation.
+ Incompatible with the --interactive option.
++
+You may find this (or --no-ff with an interactive rebase) helpful after
+reverting a topic branch merge, as this option recreates the topic branch with
+fresh commits so it can be remerged successfully without needing to "revert
+the reversion" (see the
+link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
--ignore-whitespace::
--whitespace=<option>::
@@ -316,7 +323,19 @@ which makes little sense.
commit to be modified, and change the action of the moved
commit from `pick` to `squash` (or `fixup`).
+
-This option is only valid when '--interactive' option is used.
+This option is only valid when the '--interactive' option is used.
+
+--no-ff::
+ With --interactive, cherry-pick all rebased commits instead of
+ fast-forwarding over the unchanged ones. This ensures that the
+ entire history of the rebased branch is composed of new commits.
++
+Without --interactive, this is a synonym for --force-rebase.
++
+You may find this helpful after reverting a topic branch merge, as this option
+recreates the topic branch with fresh commits so it can be remerged
+successfully without needing to "revert the reversion" (see the
+link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
include::merge-strategies.txt[]
diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt
index 3b4a390005..ff5c0bc27a 100644
--- a/Documentation/howto/revert-a-faulty-merge.txt
+++ b/Documentation/howto/revert-a-faulty-merge.txt
@@ -142,6 +142,8 @@ different resolution strategies:
revert of a merge was rebuilt from scratch (i.e. rebasing and fixing,
as you seem to have interpreted), then re-merging the result without
doing anything else fancy would be the right thing to do.
+ (See the ADDENDUM below for how to rebuild a branch from scratch
+ without changing its original branching-off point.)
However, there are things to keep in mind when reverting a merge (and
reverting such a revert).
@@ -177,3 +179,91 @@ the answer is: "oops, I really shouldn't have merged it, because it wasn't
ready yet, and I really need to undo _all_ of the merge"). So then you
really should revert the merge, but when you want to re-do the merge, you
now need to do it by reverting the revert.
+
+ADDENDUM
+
+Sometimes you have to rewrite one of a topic branch's commits *and* you can't
+change the topic's branching-off point. Consider the following situation:
+
+ P---o---o---M---x---x---W---x
+ \ /
+ A---B---C
+
+where commit W reverted commit M because it turned out that commit B was wrong
+and needs to be rewritten, but you need the rewritten topic to still branch
+from commit P (perhaps P is a branching-off point for yet another branch, and
+you want be able to merge the topic into both branches).
+
+The natural thing to do in this case is to checkout the A-B-C branch and use
+"rebase -i P" to change commit B. However this does not rewrite commit A,
+because "rebase -i" by default fast-forwards over any initial commits selected
+with the "pick" command. So you end up with this:
+
+ P---o---o---M---x---x---W---x
+ \ /
+ A---B---C <-- old branch
+ \
+ B'---C' <-- naively rewritten branch
+
+To merge A-B'-C' into the mainline branch you would still have to first revert
+commit W in order to pick up the changes in A, but then it's likely that the
+changes in B' will conflict with the original B changes re-introduced by the
+reversion of W.
+
+However, you can avoid these problems if you recreate the entire branch,
+including commit A:
+
+ A'---B'---C' <-- completely rewritten branch
+ /
+ P---o---o---M---x---x---W---x
+ \ /
+ A---B---C
+
+You can merge A'-B'-C' into the mainline branch without worrying about first
+reverting W. Mainline's history would look like this:
+
+ A'---B'---C'------------------
+ / \
+ P---o---o---M---x---x---W---x---M2
+ \ /
+ A---B---C
+
+But if you don't actually need to change commit A, then you need some way to
+recreate it as a new commit with the same changes in it. The rebase commmand's
+--no-ff option provides a way to do this:
+
+ $ git rebase [-i] --no-ff P
+
+The --no-ff option creates a new branch A'-B'-C' with all-new commits (all the
+SHA IDs will be different) even if in the interactive case you only actually
+modify commit B. You can then merge this new branch directly into the mainline
+branch and be sure you'll get all of the branch's changes.
+
+You can also use --no-ff in cases where you just add extra commits to the topic
+to fix it up. Let's revisit the situation discussed at the start of this howto:
+
+ P---o---o---M---x---x---W---x
+ \ /
+ A---B---C----------------D---E <-- fixed-up topic branch
+
+At this point, you can use --no-ff to recreate the topic branch:
+
+ $ git checkout E
+ $ git rebase --no-ff P
+
+yielding
+
+ A'---B'---C'------------D'---E' <-- recreated topic branch
+ /
+ P---o---o---M---x---x---W---x
+ \ /
+ A---B---C----------------D---E
+
+You can merge the recreated branch into the mainline without reverting commit W,
+and mainline's history will look like this:
+
+ A'---B'---C'------------D'---E'
+ / \
+ P---o---o---M---x---x---W---x---M2
+ \ /
+ A---B---C