X-Git-Url: https://git.tokkee.org/?a=blobdiff_plain;f=Documentation%2Fgit-rebase.txt;h=4b10304740f5035095c19be05859ae0b9205e9a0;hb=175f5595511b047a320e5c6163c642ac1fc34681;hp=e8e75790fc21b403f428b8cca72ab42a072e1b38;hpb=66d4035e1099477aa488c24c0c081ee764f85868;p=git.git

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index e8e75790f..4b1030474 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -9,6 +9,7 @@ SYNOPSIS
 --------
 [verse]
 'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
+	[-s <strategy> | --strategy=<strategy>]
 	[-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
 	[--onto <newbase>] <upstream> [<branch>]
 'git-rebase' --continue | --skip | --abort
@@ -28,7 +29,10 @@ The current branch is reset to <upstream>, or <newbase> if the
 `git reset --hard <upstream>` (or <newbase>).
 
 The commits that were previously saved into the temporary area are
-then reapplied to the current branch, one by one, in order.
+then reapplied to the current branch, one by one, in order. Note that
+any commits in HEAD which introduce the same textual changes as a commit
+in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream
+with a different commit message or timestamp will be skipped).
 
 It is possible that a merge failure will prevent this process from being
 completely automatic.  You will have to resolve any such merge failure
@@ -62,6 +66,26 @@ would be:
 The latter form is just a short-hand of `git checkout topic`
 followed by `git rebase master`.
 
+If the upstream branch already contains a change you have made (e.g.,
+because you mailed a patch which was applied upstream), then that commit
+will be skipped. For example, running `git-rebase master` on the
+following history (in which A' and A introduce the same set of changes,
+but have different committer information):
+
+------------
+          A---B---C topic
+         /
+    D---E---A'---F master
+------------
+
+will result in:
+
+------------
+                   B'---C' topic
+                  /
+    D---E---A'---F master
+------------
+
 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`.
@@ -212,7 +236,7 @@ OPTIONS
 
 --whitespace=<nowarn|warn|error|error-all|strip>::
 	This flag is passed to the `git-apply` program
-	(see gitlink:git-apply[1]) that applies the patch.
+	(see linkgit:git-apply[1]) that applies the patch.
 
 -i, \--interactive::
 	Make a list of the commits which are about to be rebased.  Let the
@@ -351,8 +375,8 @@ add other commits.  This can be used to split a commit into two:
   However, the working tree stays the same.
 
 - Now add the changes to the index that you want to have in the first
-  commit.  You can use gitlink:git-add[1] (possibly interactively) and/or
-  gitlink:git-gui[1] to do that.
+  commit.  You can use linkgit:git-add[1] (possibly interactively) and/or
+  linkgit:git-gui[1] to do that.
 
 - Commit the now-current index with whatever commit message is appropriate
   now.
@@ -363,7 +387,7 @@ add other commits.  This can be used to split a commit into two:
 
 If you are not absolutely sure that the intermediate revisions are
 consistent (they compile, pass the testsuite, etc.) you should use
-gitlink:git-stash[1] to stash away the not-yet-committed changes
+linkgit:git-stash[1] to stash away the not-yet-committed changes
 after each commit, test, and amend the commit if fixes are necessary.
 
 
@@ -378,4 +402,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
 
 GIT
 ---
-Part of the gitlink:git[7] suite
+Part of the linkgit:git[7] suite