Autogenerated HTML docs for v1.5.6.1-156-ge903b

1 files changed, 19 insertions, 19 deletions

diff --git a/git-rebase.txt b/git-rebase.txt
index 716641435..754230e46 100644
--- a/git-rebase.txt
+++ b/git-rebase.txt
@@ -8,15 +8,15 @@ git-rebase - Forward-port local commits to the updated upstream head
 SYNOPSIS
 --------
 [verse]
-'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
+'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
+'git rebase' --continue | --skip | --abort
 
 DESCRIPTION
 -----------
-If <branch> is specified, git-rebase will perform an automatic
+If <branch> is specified, `git-rebase` will perform an automatic
 `git checkout <branch>` before doing anything else.  Otherwise
 it remains on the current branch.
 
@@ -52,8 +52,8 @@ Assume the following history exists and the current branch is "topic":
 From this point, the result of either of the following commands:
 
 
-    git-rebase master
-    git-rebase master topic
+    git rebase master
+    git rebase master topic
 
 would be:
 
@@ -68,7 +68,7 @@ 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
+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):
 
@@ -116,7 +116,7 @@ got merged into more stable 'master' branch, like this:
 
 We can get this using the following command:
 
-    git-rebase --onto master next topic
+    git rebase --onto master next topic
 
 
 Another example of --onto option is to rebase part of a
@@ -132,7 +132,7 @@ branch.  If we have the following situation:
 
 then the command
 
-    git-rebase --onto master topicA topicB
+    git rebase --onto master topicA topicB
 
 would result in:
 
@@ -155,7 +155,7 @@ the following situation:
 
 then the command
 
-    git-rebase --onto topicA~5 topicA~3 topicA
+    git rebase --onto topicA~5 topicA~3 topicA
 
 would result in the removal of commits F and G:
 
@@ -167,8 +167,8 @@ This is useful if F and G were flawed in some way, or should not be
 part of topicA.  Note that the argument to --onto and the <upstream>
 parameter can be any valid commit-ish.
 
-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
+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
 file you edit, you need to tell git that the conflict has been resolved,
 typically this would be done with
@@ -184,7 +184,7 @@ desired resolution, you can continue the rebasing process with
     git rebase --continue
 
 
-Alternatively, you can undo the git-rebase with
+Alternatively, you can undo the `git-rebase` with
 
 
     git rebase --abort
@@ -364,34 +364,34 @@ SPLITTING COMMITS
 -----------------
 
 In interactive mode, you can mark commits with the action "edit".  However,
-this does not necessarily mean that 'git rebase' expects the result of this
+this does not necessarily mean that `git-rebase` expects the result of this
 edit to be exactly one commit.  Indeed, you can undo the commit, or you can
 add other commits.  This can be used to split a commit into two:
 
-- Start an interactive rebase with 'git rebase -i <commit>^', where
+- Start an interactive rebase with `git rebase -i <commit>^`, where
   <commit> is the commit you want to split.  In fact, any commit range
   will do, as long as it contains that commit.
 
 - Mark the commit you want to split with the action "edit".
 
-- When it comes to editing that commit, execute 'git reset HEAD^'.  The
+- When it comes to editing that commit, execute `git reset HEAD^`.  The
   effect is that the HEAD is rewound by one, and the index follows suit.
   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 linkgit:git-add[1] (possibly interactively) and/or
-  linkgit:git-gui[1] to do that.
+  commit.  You can use `git add` (possibly interactively) or
+  `git-gui` (or both) to do that.
 
 - Commit the now-current index with whatever commit message is appropriate
   now.
 
 - Repeat the last two steps until your working tree is clean.
 
-- Continue the rebase with 'git rebase --continue'.
+- Continue the rebase with `git rebase --continue`.
 
 If you are not absolutely sure that the intermediate revisions are
 consistent (they compile, pass the testsuite, etc.) you should use
-linkgit:git-stash[1] to stash away the not-yet-committed changes
+`git-stash` to stash away the not-yet-committed changes
 after each commit, test, and amend the commit if fixes are necessary.