Documentation formatting and cleanup
Following what appears to be the predominant style, format
names of commands and commandlines both as `teletype text`.
While we're at it, add articles ("a" and "the") in some
places, italicize the name of the command in the manual page
synopsis line, and add a comma or two where it seems appropriate.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2753f74..754230e 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -16,7 +16,7 @@
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.
@@ -167,8 +167,8 @@
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 @@
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 @@
-----------------
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.
