Merge branch 'dp/clean-fix'

[git.git] / Documentation / git-rebase.txt

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index e8e75790fc21b403f428b8cca72ab42a072e1b38..4b10304740f5035095c19be05859ae0b9205e9a0 100644 (file)
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -9,6 +9,7 @@ SYNOPSIS
 --------
 [verse]
 'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
 --------
 [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
        [-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
 `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
 
 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`.
 
 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`.
 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
 
 --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
 
 -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
   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.
 
 - 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
 
 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.
 
 
 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
 ---
 
 GIT
 ---

-Part of the gitlink:git[7] suite
+Part of the linkgit:git[7] suite