Stop ignoring Documentation/README
[gitweb.git] / Documentation / git-rebase.txt
index 08ee4aabaf74c8691a67c974bf3dca1c28cf25bc..0cb9e1f10a26866eb0c908ed9a6f7a81d23532e7 100644 (file)
@@ -3,11 +3,11 @@ git-rebase(1)
 
 NAME
 ----
-git-rebase - Rebase local commits to a new head
+git-rebase - Forward-port local commits to the updated upstream head
 
 SYNOPSIS
 --------
-'git-rebase' [--onto <newbase>] <upstream> [<branch>]
+'git-rebase' [-v] [--merge] [--onto <newbase>] <upstream> [<branch>]
 
 'git-rebase' --continue | --skip | --abort
 
@@ -51,20 +51,69 @@ would be:
     D---E---F---G master
 ------------
 
-While, starting from the same point, the result of either of the following
-commands:
+The latter form is just a short-hand of `git checkout topic`
+followed by `git rebase master`.
 
-    git-rebase --onto master~1 master
-    git-rebase --onto master~1 master topic
+Here is how you would transplant a topic branch based on one
+branch to another, to pretend that you forked the topic branch
+from the latter branch, using `rebase --onto`.
 
-would be:
+First let's assume your 'topic' is based on branch 'next'.
+For example feature developed in 'topic' depends on some
+functionality which is found in 'next'.
 
 ------------
-              A'--B'--C' topic
-             /
-    D---E---F---G master
+    o---o---o---o---o  master
+         \
+          o---o---o---o---o  next
+                           \
+                            o---o---o  topic
+------------
+
+We would want to make 'topic' forked from branch 'master',
+for example because the functionality 'topic' branch depend on
+got merged into more stable 'master' branch, like this:
+
+------------
+    o---o---o---o---o  master
+        |            \
+        |             o'--o'--o'  topic
+         \
+          o---o---o---o---o  next
+------------
+
+We can get this using the following command:
+
+    git-rebase --onto master next topic
+
+
+Another example of --onto option is to rebase part of a
+branch.  If we have the following situation:
+
+------------
+                            H---I---J topicB
+                           /
+                  E---F---G  topicA
+                 /
+    A---B---C---D  master
+------------
+
+then the command
+
+    git-rebase --onto master topicA topicB
+
+would result in:
+
+------------
+                 H'--I'--J'  topicB
+                /
+                | E---F---G  topicA
+                |/
+    A---B---C---D  master
 ------------
 
+This is useful when topicB does not depend on topicA.
+
 In case of conflict, git-rebase will stop at the first problematic commit
 and leave conflict markers in the tree.  You can use git diff to locate
 the markers (<<<<<<) and make edits to resolve the conflict.  For each
@@ -106,6 +155,26 @@ OPTIONS
 --abort::
        Restore the original branch and abort the rebase operation.
 
+--skip::
+       Restart the rebasing process by skipping the current patch.
+
+--merge::
+       Use merging strategies to rebase.  When the recursive (default) merge
+       strategy is used, this allows rebase to be aware of renames on the
+       upstream side.
+
+-s <strategy>, \--strategy=<strategy>::
+       Use the given merge strategy; can be supplied more than
+       once to specify them in the order they should be tried.
+       If there is no `-s` option, a built-in list of strategies
+       is used instead (`git-merge-recursive` when merging a single
+       head, `git-merge-octopus` otherwise).  This implies --merge.
+
+-v, \--verbose::
+       Display a diffstat of what changed upstream since the last rebase.
+
+include::merge-strategies.txt[]
+
 NOTES
 -----
 When you rebase a branch, you are changing its history in a way that