git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* [RFC PATCH v1 00/13][GSoC] doc: (monospace) apply CodingGuidelines on a large-scale
@ 2021-04-09  4:02 Firmin Martin
  2021-04-09  4:02 ` [RFC PATCH v1 01/13] doc: typeset command-line options in monospace Firmin Martin
                   ` (13 more replies)
  0 siblings, 14 replies; 20+ messages in thread
From: Firmin Martin @ 2021-04-09  4:02 UTC (permalink / raw)
  To: git; +Cc: Firmin Martin

This patch series aims to make the documentation fully compliant to the
CodingGuidelines regarding monospace font. After it, new contributors
who just want to change a little portion of the documention could just
look around how it has been done without being confused by the
inconsistency between the documentation and the CodingGuidelines.

Concretely: unquoted, single-quoted or double-quoted entities detailed
below in the summary are wrapped or converted in backticks.

Except some easy cases, the methodology consists of using simple regex
to find relevant files, then interactively substitute targeted entities
with progressively smarter regex to exclude false positives. As the
review process could be very tedious, I have been very cautious and have
reviewed myself a couple of times every changes. Consequently, mistakes,
if there are any, are not due to the regex, but my personal
misinterpretation of the context.

Below is some changes I plan to make in v2 which request
comments/approvals of the community.

* Placeholders and option values should be in italic. (Cf. man man) 
    - e.g. `--date`='<format>', `--notes`[='<ref>'], `branch.`'<name>'`.remote`
    - e.g. `--date`='rfc2822'
    - Compare gcc and git-add
        - man gcc vs. man git-add 
        - https://linux.die.net/man/1/gcc vs. https://linux.die.net/man/1/git-add
* The Synopsis section should be formatted based on the current
CodingGuidelines plus the above suggestion. IOW, for instance, options should
be wrapped in backticks. Again, to have an idea, compare gcc and git-add. 

Best,

Firmin

Firmin Martin (13):
  doc: typeset command-line options in monospace
  doc: typeset branches and remotes in monospace
  doc: typeset configuration options in monospace
  doc: typeset git-related commands in monospace
  doc: typeset git-svn subcommands in monospace
  doc: typeset dummy URLs and protocols in monospace
  doc: typeset git dotfiles in monospace
  doc: typeset filepath and $variables in monospace
  doc: typeset command/option/value entries in monospace
  doc: typeset more command entries in monospace
  doc: typeset config option entries in monospace
  doc: typeset environment vars without $ in monospace
  doc: typeset common programs in monospace

 Documentation/CodingGuidelines                |   2 +-
 Documentation/MyFirstContribution.txt         |   8 +-
 Documentation/SubmittingPatches               |   2 +-
 Documentation/blame-options.txt               |  50 +-
 Documentation/config.txt                      |  38 +-
 Documentation/config/diff.txt                 |   2 +-
 Documentation/config/gitcvs.txt               |   6 +-
 Documentation/diff-format.txt                 |  12 +-
 Documentation/diff-generate-patch.txt         |   8 +-
 Documentation/diff-options.txt                | 252 +++----
 Documentation/fetch-options.txt               | 136 ++--
 Documentation/git-add.txt                     |  86 +--
 Documentation/git-am.txt                      | 116 +--
 Documentation/git-apply.txt                   |  84 +--
 Documentation/git-archimport.txt              |  34 +-
 Documentation/git-archive.txt                 |  52 +-
 Documentation/git-bisect-lk2009.txt           | 188 ++---
 Documentation/git-bisect.txt                  |  48 +-
 Documentation/git-blame.txt                   |  32 +-
 Documentation/git-branch.txt                  | 156 ++--
 Documentation/git-bugreport.txt               |  14 +-
 Documentation/git-bundle.txt                  |  74 +-
 Documentation/git-cat-file.txt                |  42 +-
 Documentation/git-check-attr.txt              |  18 +-
 Documentation/git-check-ignore.txt            |  16 +-
 Documentation/git-check-mailmap.txt           |   4 +-
 Documentation/git-check-ref-format.txt        |  16 +-
 Documentation/git-checkout-index.txt          |  42 +-
 Documentation/git-checkout.txt                | 114 +--
 Documentation/git-cherry-pick.txt             |  76 +-
 Documentation/git-cherry.txt                  |  20 +-
 Documentation/git-citool.txt                  |   6 +-
 Documentation/git-clean.txt                   |  66 +-
 Documentation/git-clone.txt                   | 104 +--
 Documentation/git-column.txt                  |  26 +-
 Documentation/git-commit-graph.txt            |  12 +-
 Documentation/git-commit-tree.txt             |  22 +-
 Documentation/git-commit.txt                  | 174 ++---
 Documentation/git-config.txt                  | 174 ++---
 Documentation/git-count-objects.txt           |  16 +-
 .../git-credential-cache--daemon.txt          |   2 +-
 Documentation/git-credential-cache.txt        |   8 +-
 Documentation/git-credential-store.txt        |  12 +-
 Documentation/git-credential.txt              |  16 +-
 Documentation/git-cvsexportcommit.txt         |  46 +-
 Documentation/git-cvsimport.txt               |  84 +--
 Documentation/git-cvsserver.txt               | 110 +--
 Documentation/git-daemon.txt                  | 150 ++--
 Documentation/git-describe.txt                |  80 +-
 Documentation/git-diff-files.txt              |  18 +-
 Documentation/git-diff-index.txt              |  34 +-
 Documentation/git-diff-tree.txt               |  46 +-
 Documentation/git-diff.txt                    |  64 +-
 Documentation/git-difftool.txt                |  78 +-
 Documentation/git-fast-export.txt             |  84 +--
 Documentation/git-fast-import.txt             | 140 ++--
 Documentation/git-fetch-pack.txt              |  72 +-
 Documentation/git-fetch.txt                   |  46 +-
 Documentation/git-filter-branch.txt           | 164 ++---
 Documentation/git-fmt-merge-msg.txt           |  30 +-
 Documentation/git-for-each-ref.txt            |  80 +-
 Documentation/git-for-each-repo.txt           |   4 +-
 Documentation/git-format-patch.txt            | 132 ++--
 Documentation/git-fsck-objects.txt            |   2 +-
 Documentation/git-fsck.txt                    |  74 +-
 Documentation/git-gc.txt                      |  36 +-
 Documentation/git-get-tar-commit-id.txt       |   8 +-
 Documentation/git-grep.txt                    | 178 ++---
 Documentation/git-gui.txt                     |  32 +-
 Documentation/git-hash-object.txt             |  20 +-
 Documentation/git-help.txt                    |  78 +-
 Documentation/git-http-backend.txt            |  72 +-
 Documentation/git-http-fetch.txt              |  24 +-
 Documentation/git-http-push.txt               |  22 +-
 Documentation/git-imap-send.txt               |  20 +-
 Documentation/git-index-pack.txt              |  48 +-
 Documentation/git-init-db.txt                 |   2 +-
 Documentation/git-init.txt                    |  28 +-
 Documentation/git-instaweb.txt                |  44 +-
 Documentation/git-interpret-trailers.txt      |  80 +-
 Documentation/git-log.txt                     |  56 +-
 Documentation/git-ls-files.txt                | 126 ++--
 Documentation/git-ls-remote.txt               |  46 +-
 Documentation/git-ls-tree.txt                 |  38 +-
 Documentation/git-mailinfo.txt                |  36 +-
 Documentation/git-mailsplit.txt               |  20 +-
 Documentation/git-maintenance.txt             |  32 +-
 Documentation/git-merge-base.txt              |  32 +-
 Documentation/git-merge-file.txt              |  26 +-
 Documentation/git-merge-index.txt             |  16 +-
 Documentation/git-merge-one-file.txt          |   6 +-
 Documentation/git-merge-tree.txt              |   4 +-
 Documentation/git-merge.txt                   |  78 +-
 Documentation/git-mergetool--lib.txt          |   8 +-
 Documentation/git-mergetool.txt               |  40 +-
 Documentation/git-mktag.txt                   |   4 +-
 Documentation/git-mktree.txt                  |   8 +-
 Documentation/git-multi-pack-index.txt        |  18 +-
 Documentation/git-mv.txt                      |  28 +-
 Documentation/git-name-rev.txt                |  32 +-
 Documentation/git-notes.txt                   | 170 ++---
 Documentation/git-p4.txt                      | 318 ++++----
 Documentation/git-pack-objects.txt            | 122 ++--
 Documentation/git-pack-redundant.txt          |  10 +-
 Documentation/git-pack-refs.txt               |  12 +-
 Documentation/git-patch-id.txt                |  22 +-
 Documentation/git-prune-packed.txt            |  10 +-
 Documentation/git-prune.txt                   |  30 +-
 Documentation/git-pull.txt                    |  42 +-
 Documentation/git-push.txt                    | 136 ++--
 Documentation/git-quiltimport.txt             |  18 +-
 Documentation/git-range-diff.txt              |  16 +-
 Documentation/git-read-tree.txt               | 118 +--
 Documentation/git-rebase.txt                  | 384 +++++-----
 Documentation/git-receive-pack.txt            |  48 +-
 Documentation/git-reflog.txt                  |  36 +-
 Documentation/git-remote-ext.txt              |  40 +-
 Documentation/git-remote-fd.txt               |  16 +-
 Documentation/git-remote.txt                  |  62 +-
 Documentation/git-repack.txt                  |  64 +-
 Documentation/git-replace.txt                 |  42 +-
 Documentation/git-request-pull.txt            |  12 +-
 Documentation/git-rerere.txt                  |  80 +-
 Documentation/git-reset.txt                   |  60 +-
 Documentation/git-restore.txt                 |  58 +-
 Documentation/git-rev-list.txt                |   6 +-
 Documentation/git-rev-parse.txt               | 148 ++--
 Documentation/git-revert.txt                  |  54 +-
 Documentation/git-rm.txt                      |  32 +-
 Documentation/git-send-email.txt              | 192 ++---
 Documentation/git-send-pack.txt               |  44 +-
 Documentation/git-sh-i18n--envsubst.txt       |   2 +-
 Documentation/git-sh-i18n.txt                 |   4 +-
 Documentation/git-sh-setup.txt                |  10 +-
 Documentation/git-shell.txt                   |  26 +-
 Documentation/git-shortlog.txt                |  32 +-
 Documentation/git-show-branch.txt             |  66 +-
 Documentation/git-show-index.txt              |   4 +-
 Documentation/git-show-ref.txt                |  58 +-
 Documentation/git-show.txt                    |  12 +-
 Documentation/git-sparse-checkout.txt         |  18 +-
 Documentation/git-stage.txt                   |   2 +-
 Documentation/git-stash.txt                   |  80 +-
 Documentation/git-status.txt                  |  78 +-
 Documentation/git-stripspace.txt              |  16 +-
 Documentation/git-submodule.txt               | 172 ++---
 Documentation/git-svn.txt                     | 690 +++++++++---------
 Documentation/git-switch.txt                  |  76 +-
 Documentation/git-symbolic-ref.txt            |  22 +-
 Documentation/git-tag.txt                     | 108 +--
 Documentation/git-unpack-file.txt             |   4 +-
 Documentation/git-unpack-objects.txt          |  12 +-
 Documentation/git-update-index.txt            | 132 ++--
 Documentation/git-update-ref.txt              |  40 +-
 Documentation/git-update-server-info.txt      |   6 +-
 Documentation/git-upload-archive.txt          |  10 +-
 Documentation/git-upload-pack.txt             |  20 +-
 Documentation/git-var.txt                     |  20 +-
 Documentation/git-verify-commit.txt           |  10 +-
 Documentation/git-verify-pack.txt             |  14 +-
 Documentation/git-verify-tag.txt              |  10 +-
 Documentation/git-web--browse.txt             |  26 +-
 Documentation/git-whatchanged.txt             |   8 +-
 Documentation/git-worktree.txt                |  74 +-
 Documentation/git-write-tree.txt              |  12 +-
 Documentation/git.txt                         | 142 ++--
 Documentation/gitattributes.txt               |  88 +--
 Documentation/gitcli.txt                      |   6 +-
 Documentation/gitcore-tutorial.txt            | 212 +++---
 Documentation/gitcredentials.txt              |  20 +-
 Documentation/gitcvs-migration.txt            |  14 +-
 Documentation/gitdiffcore.txt                 |  60 +-
 Documentation/giteveryday.txt                 |  24 +-
 Documentation/gitfaq.txt                      |   6 +-
 Documentation/githooks.txt                    |  26 +-
 Documentation/gitignore.txt                   |  16 +-
 Documentation/gitk.txt                        |  64 +-
 Documentation/gitmailmap.txt                  |   2 +-
 Documentation/gitmodules.txt                  |  26 +-
 Documentation/gitnamespaces.txt               |  12 +-
 Documentation/gitremote-helpers.txt           |  90 +--
 Documentation/gitrepository-layout.txt        | 114 +--
 Documentation/gitsubmodules.txt               |   2 +-
 Documentation/gittutorial-2.txt               |  38 +-
 Documentation/gittutorial.txt                 | 100 +--
 Documentation/gitweb.conf.txt                 | 320 ++++----
 Documentation/gitweb.txt                      | 168 ++---
 Documentation/gitworkflows.txt                |  76 +-
 Documentation/glossary-content.txt            |  38 +-
 Documentation/howto/revert-branch-rebase.txt  |   2 +-
 .../howto/setup-git-server-over-http.txt      |   2 +-
 Documentation/i18n.txt                        |   4 +-
 Documentation/merge-options.txt               | 100 +--
 Documentation/merge-strategies.txt            |  36 +-
 Documentation/pretty-formats.txt              |  16 +-
 Documentation/pretty-options.txt              |  52 +-
 Documentation/pull-fetch-param.txt            |  18 +-
 Documentation/rev-list-options.txt            | 242 +++---
 Documentation/revisions.txt                   |  76 +-
 Documentation/sequencer.txt                   |   8 +-
 Documentation/signoff-option.txt              |   8 +-
 Documentation/urls-remotes.txt                |  12 +-
 Documentation/urls.txt                        |  40 +-
 Documentation/user-manual.txt                 | 116 +--
 204 files changed, 5971 insertions(+), 5971 deletions(-)

-- 
2.31.1.133.g84d06cdc06


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [RFC PATCH v1 01/13] doc: typeset command-line options in monospace
  2021-04-09  4:02 [RFC PATCH v1 00/13][GSoC] doc: (monospace) apply CodingGuidelines on a large-scale Firmin Martin
@ 2021-04-09  4:02 ` Firmin Martin
  2021-04-09  9:49   ` Bagas Sanjaya
  2021-04-09  4:02 ` [RFC PATCH v1 02/13] doc: typeset branches and remotes " Firmin Martin
                   ` (12 subsequent siblings)
  13 siblings, 1 reply; 20+ messages in thread
From: Firmin Martin @ 2021-04-09  4:02 UTC (permalink / raw)
  To: git; +Cc: Firmin Martin

Wrap command-line options with backticks as indicated in the
CodingGuidelines.

The following command and regex assisted the process.

    REGEX="^(?![[:blank:]]*[\$]).*[^-\`+<[:punct:][:alnum:]]\-{1,2}[[:alpha:]][a-z0-9-]*(=[\"<]?([[:alnum:]])+[>\"]?)?[^\`-]" &&
    grep -Pn "$REGEX" *.txt --exclude-dir=RelNotes

Signed-off-by: Firmin Martin <firminmartin24@gmail.com>
---
 Documentation/SubmittingPatches               |   2 +-
 Documentation/blame-options.txt               |   6 +-
 Documentation/config/diff.txt                 |   2 +-
 Documentation/config/gitcvs.txt               |   6 +-
 Documentation/diff-generate-patch.txt         |   4 +-
 Documentation/diff-options.txt                |   8 +-
 Documentation/fetch-options.txt               |  16 +--
 Documentation/git-add.txt                     |   2 +-
 Documentation/git-apply.txt                   |   2 +-
 Documentation/git-archimport.txt              |   2 +-
 Documentation/git-archive.txt                 |   2 +-
 Documentation/git-branch.txt                  |   2 +-
 Documentation/git-bundle.txt                  |  10 +-
 Documentation/git-checkout-index.txt          |   6 +-
 Documentation/git-checkout.txt                |   4 +-
 Documentation/git-cherry-pick.txt             |   2 +-
 Documentation/git-clean.txt                   |   8 +-
 Documentation/git-clone.txt                   |   4 +-
 Documentation/git-column.txt                  |   2 +-
 Documentation/git-commit.txt                  |  16 +--
 Documentation/git-config.txt                  |   6 +-
 Documentation/git-count-objects.txt           |   6 +-
 Documentation/git-cvsexportcommit.txt         |   8 +-
 Documentation/git-cvsimport.txt               |  12 +-
 Documentation/git-cvsserver.txt               |  12 +-
 Documentation/git-daemon.txt                  |  22 ++--
 Documentation/git-describe.txt                |  18 +--
 Documentation/git-diff-tree.txt               |   6 +-
 Documentation/git-diff.txt                    |   6 +-
 Documentation/git-fast-export.txt             |  10 +-
 Documentation/git-fast-import.txt             |  42 +++----
 Documentation/git-fetch-pack.txt              |   4 +-
 Documentation/git-fetch.txt                   |   6 +-
 Documentation/git-filter-branch.txt           |  26 ++---
 Documentation/git-fmt-merge-msg.txt           |   2 +-
 Documentation/git-for-each-ref.txt            |   4 +-
 Documentation/git-format-patch.txt            |   6 +-
 Documentation/git-fsck.txt                    |   6 +-
 Documentation/git-gc.txt                      |   4 +-
 Documentation/git-grep.txt                    |   4 +-
 Documentation/git-help.txt                    |   8 +-
 Documentation/git-http-fetch.txt              |   2 +-
 Documentation/git-http-push.txt               |   2 +-
 Documentation/git-index-pack.txt              |  12 +-
 Documentation/git-init.txt                    |   2 +-
 Documentation/git-interpret-trailers.txt      |  18 +--
 Documentation/git-ls-files.txt                |  24 ++--
 Documentation/git-ls-remote.txt               |   2 +-
 Documentation/git-ls-tree.txt                 |   6 +-
 Documentation/git-mailinfo.txt                |   4 +-
 Documentation/git-mailsplit.txt               |   2 +-
 Documentation/git-merge-index.txt             |   2 +-
 Documentation/git-mv.txt                      |   2 +-
 Documentation/git-name-rev.txt                |  10 +-
 Documentation/git-notes.txt                   |   4 +-
 Documentation/git-p4.txt                      |  26 ++---
 Documentation/git-pack-objects.txt            |  36 +++---
 Documentation/git-patch-id.txt                |   6 +-
 Documentation/git-prune.txt                   |   2 +-
 Documentation/git-pull.txt                    |   6 +-
 Documentation/git-push.txt                    |  10 +-
 Documentation/git-quiltimport.txt             |   2 +-
 Documentation/git-read-tree.txt               |   6 +-
 Documentation/git-rebase.txt                  | 108 +++++++++---------
 Documentation/git-repack.txt                  |   2 +-
 Documentation/git-reset.txt                   |   4 +-
 Documentation/git-rev-parse.txt               |   6 +-
 Documentation/git-rm.txt                      |   2 +-
 Documentation/git-send-email.txt              |  42 +++----
 Documentation/git-send-pack.txt               |   2 +-
 Documentation/git-show-branch.txt             |   2 +-
 Documentation/git-show-ref.txt                |  12 +-
 Documentation/git-status.txt                  |  10 +-
 Documentation/git-submodule.txt               |   2 +-
 Documentation/git-svn.txt                     |  76 ++++++------
 Documentation/git-tag.txt                     |   4 +-
 Documentation/git-update-index.txt            |  12 +-
 Documentation/git-update-ref.txt              |   6 +-
 Documentation/git-verify-pack.txt             |   2 +-
 Documentation/git-web--browse.txt             |   2 +-
 Documentation/git-whatchanged.txt             |   2 +-
 Documentation/git.txt                         |   4 +-
 Documentation/gitcore-tutorial.txt            |   2 +-
 Documentation/gitdiffcore.txt                 |  30 ++---
 Documentation/gitk.txt                        |   6 +-
 Documentation/gittutorial-2.txt               |   4 +-
 Documentation/gittutorial.txt                 |   4 +-
 Documentation/gitweb.conf.txt                 |   6 +-
 Documentation/howto/revert-branch-rebase.txt  |   2 +-
 .../howto/setup-git-server-over-http.txt      |   2 +-
 Documentation/merge-options.txt               |  22 ++--
 Documentation/pretty-formats.txt              |  12 +-
 Documentation/pretty-options.txt              |  20 ++--
 Documentation/rev-list-options.txt            |  28 ++---
 Documentation/signoff-option.txt              |   2 +-
 Documentation/urls.txt                        |   4 +-
 Documentation/user-manual.txt                 |   4 +-
 97 files changed, 479 insertions(+), 479 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 0452db2e67..e7623d967b 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -158,7 +158,7 @@ invocation of `git show`:
 	git show -s --pretty=reference <commit>
 ....
 
-or, on an older version of Git without support for --pretty=reference:
+or, on an older version of Git without support for `--pretty=reference`:
 
 ....
 	git show -s --date=short --pretty='format:%h (%s, %ad)' <commit>
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 117f4cf806..860e8e2f5c 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -50,7 +50,7 @@ include::line-range-format.txt[]
 --line-porcelain::
 	Show the porcelain format, but output commit information for
 	each line, not just the first time a commit is referenced.
-	Implies --porcelain.
+	Implies `--porcelain`.
 
 --incremental::
 	Show the result incrementally in a format designed for
@@ -71,11 +71,11 @@ include::line-range-format.txt[]
 	`-` to make the command read from the standard input).
 
 --date <format>::
-	Specifies the format used to output dates. If --date is not
+	Specifies the format used to output dates. If `--date` is not
 	provided, the value of the blame.date config variable is
 	used. If the blame.date config variable is also not set, the
 	iso format is used. For supported values, see the discussion
-	of the --date option at linkgit:git-log[1].
+	of the `--date` option at linkgit:git-log[1].
 
 --[no-]progress::
 	Progress status is reported on the standard error stream
diff --git a/Documentation/config/diff.txt b/Documentation/config/diff.txt
index 2d3331f55c..7556df330c 100644
--- a/Documentation/config/diff.txt
+++ b/Documentation/config/diff.txt
@@ -113,7 +113,7 @@ diff.relative::
 
 diff.orderFile::
 	File indicating how to order files within a diff.
-	See the '-O' option to linkgit:git-diff[1] for details.
+	See the `-O` option to linkgit:git-diff[1] for details.
 	If `diff.orderFile` is a relative pathname, it is treated as
 	relative to the top of the working tree.
 
diff --git a/Documentation/config/gitcvs.txt b/Documentation/config/gitcvs.txt
index 02da427fd9..a188638340 100644
--- a/Documentation/config/gitcvs.txt
+++ b/Documentation/config/gitcvs.txt
@@ -16,16 +16,16 @@ gitcvs.usecrlfattr::
 	the attributes force Git to treat a file as text,
 	the `-k` mode will be left blank so CVS clients will
 	treat it as text. If they suppress text conversion, the file
-	will be set with '-kb' mode, which suppresses any newline munging
+	will be set with `-kb` mode, which suppresses any newline munging
 	the client might otherwise do. If the attributes do not allow
 	the file type to be determined, then `gitcvs.allBinary` is
 	used. See linkgit:gitattributes[5].
 
 gitcvs.allBinary::
 	This is used if `gitcvs.usecrlfattr` does not resolve
-	the correct '-kb' mode to use. If true, all
+	the correct `-kb` mode to use. If true, all
 	unresolved files are sent to the client in
-	mode '-kb'. This causes the client to treat them
+	mode `-kb`. This causes the client to treat them
 	as binary files, which suppresses any newline munging it
 	otherwise might do. Alternatively, if it is set to "guess",
 	then the contents of the file are examined to decide if
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
index 2db8eacc3e..2615b29cb0 100644
--- a/Documentation/diff-generate-patch.txt
+++ b/Documentation/diff-generate-patch.txt
@@ -13,7 +13,7 @@ You can customize the creation of patch text via the
 `GIT_EXTERNAL_DIFF` and the `GIT_DIFF_OPTS` environment variables
 (see linkgit:git[1]).
 
-What the -p option produces is slightly different from the traditional
+What the `-p` option produces is slightly different from the traditional
 diff format:
 
 1.   It is preceded with a "git diff" header that looks like this:
@@ -149,7 +149,7 @@ Similar to two-line header for traditional 'unified' diff
 format, `/dev/null` is used to signal created or deleted
 files.
 +
-However, if the --combined-all-paths option is provided, instead of a
+However, if the `--combined-all-paths` option is provided, instead of a
 two-line from-file/to-file you get a N+1 line from-file/to-file header,
 where N is the number of parents in the merge commit
 
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index aa2b5c11f2..13e0753862 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -471,7 +471,7 @@ ifndef::git-format-patch[]
 	that is immediately followed by a tab character inside the
 	initial indent of the line are considered whitespace errors.
 	Exits with non-zero status if problems are found. Not compatible
-	with --exit-code.
+	with `--exit-code`.
 
 --ws-error-highlight=<kind>::
 	Highlight whitespace errors in the `context`, `old` or `new`
@@ -522,10 +522,10 @@ original should remain in the result for Git to consider it a total
 rewrite (i.e. otherwise the resulting patch will be a series of
 deletion and insertion mixed together with context lines).
 +
-When used with -M, a totally-rewritten file is also considered as the
-source of a rename (usually -M only considers a file that disappeared
+When used with `-M`, a totally-rewritten file is also considered as the
+source of a rename (usually `-M` only considers a file that disappeared
 as the source of a rename), and the number `n` controls this aspect of
-the -B option (defaults to 50%). `-B20%` specifies that a change with
+the `-B` option (defaults to 50%). `-B20%` specifies that a change with
 addition and deletion compared to 20% or more of the file's size are
 eligible for being picked up as a possible source of a rename to
 another file.
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 07783deee3..4ccd65c166 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -115,10 +115,10 @@ endif::git-pull[]
 	Before fetching, remove any remote-tracking references that no
 	longer exist on the remote.  Tags are not subject to pruning
 	if they are fetched only because of the default tag
-	auto-following or due to a --tags option.  However, if tags
+	auto-following or due to a `--tags` option.  However, if tags
 	are fetched due to an explicit refspec (either on the command
 	line or in the remote configuration, for example if the remote
-	was cloned with the --mirror option), then they are also
+	was cloned with the `--mirror` option), then they are also
 	subject to pruning. Supplying `--prune-tags` is a shorthand for
 	providing the tag refspec.
 ifndef::git-pull[]
@@ -164,7 +164,7 @@ endif::git-pull[]
 	Fetch all tags from the remote (i.e., fetch remote tags
 	`refs/tags/*` into local tags with the same name), in addition
 	to whatever else would otherwise be fetched.  Using this
-	option alone does not subject tags to pruning, even if --prune
+	option alone does not subject tags to pruning, even if `--prune`
 	is used (though tags may be pruned anyway if they are also the
 	destination of an explicit refspec; see `--prune`).
 
@@ -215,7 +215,7 @@ ifndef::git-pull[]
 
 --recurse-submodules-default=[yes|on-demand]::
 	This option is used internally to temporarily provide a
-	non-negative default value for the --recurse-submodules
+	non-negative default value for the `--recurse-submodules`
 	option.  All other methods of configuring fetch's submodule
 	recursion (such as settings in linkgit:gitmodules[5] and
 	linkgit:git-config[1]) override this option, as does
@@ -240,7 +240,7 @@ endif::git-pull[]
 ifndef::git-pull[]
 -q::
 --quiet::
-	Pass --quiet to git-fetch-pack and silence any other internally
+	Pass `--quiet` to git-fetch-pack and silence any other internally
 	used git commands. Progress is not reported to the standard error
 	stream.
 
@@ -267,14 +267,14 @@ endif::git-pull[]
 --show-forced-updates::
 	By default, git checks if a branch is force-updated during
 	fetch. This can be disabled through fetch.showForcedUpdates, but
-	the --show-forced-updates option guarantees this check occurs.
+	the `--show-forced-updates` option guarantees this check occurs.
 	See linkgit:git-config[1].
 
 --no-show-forced-updates::
 	By default, git checks if a branch is force-updated during
-	fetch. Pass --no-show-forced-updates or set fetch.showForcedUpdates
+	fetch. Pass `--no-show-forced-updates` or set fetch.showForcedUpdates
 	to false to skip this check for performance reasons. If used during
-	'git-pull' the --ff-only option will still check for forced updates
+	'git-pull' the `--ff-only` option will still check for forced updates
 	before attempting a fast-forward update. See linkgit:git-config[1].
 
 -4::
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index be5e3ac54b..6a7cb07a8a 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -164,7 +164,7 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files.
 	true to make this the default behaviour.
 
 --ignore-missing::
-	This option can only be used together with --dry-run. By using
+	This option can only be used together with `--dry-run`. By using
 	this option the user can check if any of the given files would
 	be ignored, no matter if they are already present in the work
 	tree or not.
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index 91d9a8601c..f1c8098c0b 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -233,7 +233,7 @@ behavior:
 	adjusting the hunk headers appropriately).
 
 --directory=<root>::
-	Prepend <root> to all filenames.  If a "-p" argument was also passed,
+	Prepend <root> to all filenames.  If a `-p` argument was also passed,
 	it is applied before prepending the new root.
 +
 For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh`
diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt
index a595a0ffee..b477e3c495 100644
--- a/Documentation/git-archimport.txt
+++ b/Documentation/git-archimport.txt
@@ -98,7 +98,7 @@ OPTIONS
 
 -a::
 	Attempt to auto-register archives at `http://mirrors.sourcecontrol.net`
-	This is particularly useful with the -D option.
+	This is particularly useful with the `-D` option.
 
 -t <tmpdir>::
 	Override the default tempdir.
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 9f8172828d..0af18c9df3 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -77,7 +77,7 @@ OPTIONS
 	linkgit:git-upload-archive[1] for details.
 
 --exec=<git-upload-archive>::
-	Used with --remote to specify the path to the
+	Used with `--remote` to specify the path to the
 	'git-upload-archive' on the remote side.
 
 <tree-ish>::
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 94dc9a54f2..271b4ee34e 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -280,7 +280,7 @@ start-point is either a local or remote-tracking branch.
 
 --sort=<key>::
 	Sort based on the key given. Prefix `-` to sort in descending
-	order of the value. You may use the --sort=<key> option
+	order of the value. You may use the `--sort=<key>` option
 	multiple times, in which case the last key becomes the primary
 	key. The keys supported are the same as those in `git
 	for-each-ref`. Sort order defaults to the value configured for the
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 53804cad4b..4f1e59a3b2 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -88,19 +88,19 @@ unbundle <file>::
 	the standard error stream is not directed to a terminal.
 
 --all-progress::
-	When --stdout is specified then progress report is
+	When `--stdout` is specified then progress report is
 	displayed during the object count and compression phases
 	but inhibited during the write-out phase. The reason is
 	that in some cases the output stream is directly linked
 	to another command which may wish to display progress
 	status of its own as it processes incoming pack data.
-	This flag is like --progress except that it forces progress
-	report for the write-out phase as well even if --stdout is
+	This flag is like `--progress` except that it forces progress
+	report for the write-out phase as well even if `--stdout` is
 	used.
 
 --all-progress-implied::
-	This is used to imply --all-progress whenever progress display
-	is activated.  Unlike --all-progress this flag doesn't actually
+	This is used to imply `--all-progress` whenever progress display
+	is activated.  Unlike `--all-progress` this flag doesn't actually
 	force any progress display by itself.
 
 --version=<version>::
diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt
index 4d33e7be0f..b06d3ae3d9 100644
--- a/Documentation/git-checkout-index.txt
+++ b/Documentation/git-checkout-index.txt
@@ -52,7 +52,7 @@ OPTIONS
 --stage=<number>|all::
 	Instead of checking out unmerged entries, copy out the
 	files from named stage.  <number> must be between 1 and 3.
-	Note: --stage=all automatically implies --temp.
+	Note: `--stage=all` automatically implies `--temp`.
 
 --temp::
 	Instead of copying the files to the working directory
@@ -88,7 +88,7 @@ $ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
 which will force all existing `*.h` files to be replaced with their
 cached copies. If an empty command line implied "all", then this would
 force-refresh everything in the index, which was not the point.  But
-since 'git checkout-index' accepts --stdin it would be faster to use:
+since 'git checkout-index' accepts `--stdin` it would be faster to use:
 
 ----------------
 $ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
@@ -128,7 +128,7 @@ or `.` if there is no stage entry.  Paths which only have a stage 0
 entry will always be omitted from the output.
 
 In both formats RS (the record separator) is newline by default
-but will be the null byte if -z was passed on the command line.
+but will be the null byte if `-z` was passed on the command line.
 The temporary file names are always safe strings; they will never
 contain directory separators or whitespace characters.  The path
 field is always relative to the current directory and the temporary
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index b1a6fe4499..3336b8dace 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -151,13 +151,13 @@ of it").
 -B <new_branch>::
 	Creates the branch `<new_branch>` and start it at `<start_point>`;
 	if it already exists, then reset it to `<start_point>`. This is
-	equivalent to running "git branch" with "-f"; see
+	equivalent to running "git branch" with `-f`; see
 	linkgit:git-branch[1] for details.
 
 -t::
 --track::
 	When creating a new branch, set up "upstream" configuration. See
-	"--track" in linkgit:git-branch[1] for details.
+	`--track` in linkgit:git-branch[1] for details.
 +
 If no `-b` option is given, the name of the new branch will be
 derived from the remote-tracking branch, by looking at the local part of
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 5d750314b2..0127f56204 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -126,7 +126,7 @@ effect to your index in a row.
 	indicating that an explicit invocation of `git commit
 	--allow-empty` is required. This option overrides that
 	behavior, allowing empty commits to be preserved automatically
-	in a cherry-pick. Note that when "--ff" is in effect, empty
+	in a cherry-pick. Note that when `--ff` is in effect, empty
 	commits that meet the "fast-forward" requirement will be kept
 	even without this option.  Note also, that use of this option only
 	keeps commits that were initially empty (i.e. the commit recorded the
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index a7f309dff5..f4246300ae 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -28,8 +28,8 @@ OPTIONS
 -d::
 	Normally, when no <path> is specified, git clean will not
 	recurse into untracked directories to avoid removing too much.
-	Specify -d to have it recurse into such directories as well.
-	If any paths are specified, -d is irrelevant; all untracked
+	Specify `-d` to have it recurse into such directories as well.
+	If any paths are specified, `-d` is irrelevant; all untracked
 	files matching the specified paths (with exceptions for nested
 	git directories mentioned under `--force`) will be removed.
 
@@ -37,9 +37,9 @@ OPTIONS
 --force::
 	If the Git configuration variable clean.requireForce is not set
 	to false, 'git clean' will refuse to delete files or directories
-	unless given -f or -i.  Git will refuse to modify untracked
+	unless given `-f` or `-i`.  Git will refuse to modify untracked
 	nested git repositories (directories with a .git subdirectory)
-	unless a second -f is given.
+	unless a second `-f` is given.
 
 -i::
 --interactive::
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 3fe3810f1c..22334771d1 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -31,7 +31,7 @@ currently active branch.
 After the clone, a plain `git fetch` without arguments will update
 all the remote-tracking branches, and a `git pull` without
 arguments will in addition merge the remote master branch into the
-current master branch, if any (this is untrue when "--single-branch"
+current master branch, if any (this is untrue when `--single-branch`
 is given; see below).
 
 This default configuration is achieved by creating references to
@@ -52,7 +52,7 @@ OPTIONS
 	to save space when possible.
 +
 If the repository is specified as a local path (e.g., `/path/to/repo`),
-this is the default, and --local is essentially a no-op.  If the
+this is the default, and `--local` is essentially a no-op.  If the
 repository is specified as a URL, then this flag is ignored (and we
 never use the local optimizations).  Specifying `--no-local` will
 override the default when `/path/to/repo` is given, using the regular
diff --git a/Documentation/git-column.txt b/Documentation/git-column.txt
index f58e9c43e6..84a02ac15c 100644
--- a/Documentation/git-column.txt
+++ b/Documentation/git-column.txt
@@ -29,7 +29,7 @@ OPTIONS
 	syntax in linkgit:git-config[1].
 
 --raw-mode=<n>::
-	Same as --mode but take mode encoded as a number. This is mainly used
+	Same as `--mode` but take mode encoded as a number. This is mainly used
 	by other commands that have already parsed layout mode.
 
 --width=<width>::
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 340c5fbb48..6d0d663b50 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -36,18 +36,18 @@ The content to be committed can be specified in several ways:
    and the index, again before using the 'commit' command;
 
 3. by listing files as arguments to the 'commit' command
-   (without --interactive or --patch switch), in which
+   (without `--interactive` or `--patch` switch), in which
    case the commit will ignore changes staged in the index, and instead
    record the current content of the listed files (which must already
    be known to Git);
 
-4. by using the -a switch with the 'commit' command to automatically
+4. by using the `-a` switch with the 'commit' command to automatically
    "add" changes from all known files (i.e. all files that are already
    listed in the index) and to automatically "rm" files in the index
    that have been removed from the working tree, and then perform the
    actual commit;
 
-5. by using the --interactive or --patch switches with the 'commit' command
+5. by using the `--interactive` or `--patch` switches with the 'commit' command
    to decide one by one which files or hunks should be part of the commit
    in addition to contents in the index,
    before finalizing the operation. See the ``Interactive Mode'' section of
@@ -84,7 +84,7 @@ OPTIONS
 
 -c <commit>::
 --reedit-message=<commit>::
-	Like '-C', but with `-c` the editor is invoked, so that
+	Like `-C`, but with `-c` the editor is invoked, so that
 	the user can further edit the commit message.
 
 --fixup=[(amend|reword):]<commit>::
@@ -134,7 +134,7 @@ See linkgit:git-rebase[1] for details.
 	linkgit:git-rebase[1] for details.
 
 --reset-author::
-	When used with -C/-c/--amend options, or when committing after a
+	When used with `-C`/`-c`/`--amend` options, or when committing after a
 	conflicting cherry-pick, declare that the authorship of the
 	resulting commit now belongs to the committer. This also renews
 	the author timestamp.
@@ -173,7 +173,7 @@ See linkgit:git-rebase[1] for details.
 	Override the commit author. Specify an explicit author using the
 	standard `A U Thor <author@example.com>` format. Otherwise <author>
 	is assumed to be a pattern and is used to search for an existing
-	commit by that author (i.e. rev-list --all -i --author=<author>);
+	commit by that author (i.e. `git rev-list --all -i --author=<author>`);
 	the commit author is then copied from the first such commit found.
 
 --date=<date>::
@@ -223,7 +223,7 @@ include::signoff-option.txt[]
 	is primarily for use by foreign SCM interface scripts.
 
 --allow-empty-message::
-       Like --allow-empty this command is primarily for use by foreign
+       Like `--allow-empty` this command is primarily for use by foreign
        SCM interface scripts. It allows you to create a commit with an
        empty commit message without using plumbing commands like
        linkgit:git-commit-tree[1].
@@ -337,7 +337,7 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
 +
 --
 The mode parameter is optional (defaults to 'all'), and is used to
-specify the handling of untracked files; when -u is not used, the
+specify the handling of untracked files; when `-u` is not used, the
 default is 'normal', i.e. show untracked files and directories.
 
 The possible options are:
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 4b4cc5c5e8..b93394ea45 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -92,7 +92,7 @@ OPTIONS
 	Like get, but returns all values for a multi-valued key.
 
 --get-regexp::
-	Like --get-all, but interprets the name as a regular expression and
+	Like `--get-all`, but interprets the name as a regular expression and
 	writes out the key names.  Regular expression matching is currently
 	case-sensitive and done against a canonicalized version of the key
 	in which section and variable names are lowercased, but subsection
@@ -337,8 +337,8 @@ ENVIRONMENT
 
 GIT_CONFIG::
 	Take the configuration from the given file instead of .git/config.
-	Using the "--global" option forces this to ~/.gitconfig. Using the
-	"--system" option forces this to $(prefix)/etc/gitconfig.
+	Using the `--global` option forces this to ~/.gitconfig. Using the
+	`--system` option forces this to $(prefix)/etc/gitconfig.
 
 GIT_CONFIG_NOSYSTEM::
 	Whether to skip reading settings from the system-wide
diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
index cb9b4d2e46..d12ce08789 100644
--- a/Documentation/git-count-objects.txt
+++ b/Documentation/git-count-objects.txt
@@ -24,11 +24,11 @@ OPTIONS
 +
 count: the number of loose objects
 +
-size: disk space consumed by loose objects, in KiB (unless -H is specified)
+size: disk space consumed by loose objects, in KiB (unless `-H` is specified)
 +
 in-pack: the number of in-pack objects
 +
-size-pack: disk space consumed by the packs, in KiB (unless -H is specified)
+size-pack: disk space consumed by the packs, in KiB (unless `-H` is specified)
 +
 prune-packable: the number of loose objects that are also present in
 the packs. These objects could be pruned using `git prune-packed`.
@@ -36,7 +36,7 @@ the packs. These objects could be pruned using `git prune-packed`.
 garbage: the number of files in object database that are neither valid loose
 objects nor valid packs
 +
-size-garbage: disk space consumed by garbage files, in KiB (unless -H is
+size-garbage: disk space consumed by garbage files, in KiB (unless `-H` is
 specified)
 +
 alternate: absolute path of alternate object databases; may appear
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index 00154b6c85..f08ab508af 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -18,7 +18,7 @@ DESCRIPTION
 Exports a commit from Git to a CVS checkout, making it easier
 to merge patches from a Git repository into a CVS repository.
 
-Specify the name of a CVS checkout using the -w switch or execute it
+Specify the name of a CVS checkout using the `-w` switch or execute it
 from the root of the CVS working copy. In the latter case GIT_DIR must
 be defined. See examples below.
 
@@ -40,7 +40,7 @@ OPTIONS
 
 -p::
 	Be pedantic (paranoid) when applying patches. Invokes patch with
-	--fuzz=0
+	`--fuzz=0`
 
 -a::
 	Add authorship information. Adds Author line, and Committer (if
@@ -48,7 +48,7 @@ OPTIONS
 
 -d::
 	Set an alternative CVSROOT to use.  This corresponds to the CVS
-	-d parameter.  Usually users will not want to set this, except
+	`-d` parameter.  Usually users will not want to set this, except
 	if using CVS in an asymmetric fashion.
 
 -f::
@@ -99,7 +99,7 @@ $ git cvsexportcommit -v <commit-sha1>
 $ cvs commit -F .msg <files>
 ------------
 
-Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::
+Merge one patch into CVS (`-c` and `-w` options). The working directory is within the Git Repo::
 +
 ------------
 	$ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index de1ebed67d..143c726511 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -38,7 +38,7 @@ created by 'git cvsimport'.  By default initial import will create and populate
 "master" branch from the CVS repository's main branch which you're free
 to work with; after that, you need to 'git merge' incremental imports, or
 any CVS branches, yourself.  It is advisable to specify a named remote via
--r to separate and protect the incoming branches.
+`-r` to separate and protect the incoming branches.
 
 If you intend to set up a shared public repository that all developers can
 read/write, or if you want to use linkgit:git-cvsserver[1], then you
@@ -74,7 +74,7 @@ OPTIONS
 	akin to the way 'git clone' uses 'origin' by default.
 
 -o <branch-for-HEAD>::
-	When no remote is specified (via -r) the `HEAD` branch
+	When no remote is specified (via `-r`) the `HEAD` branch
 	from CVS is imported to the 'origin' branch within the Git
 	repository, as `HEAD` already has a special meaning for Git.
 	When a remote is specified the `HEAD` branch is named
@@ -82,7 +82,7 @@ OPTIONS
 	Use this option if you want to import into a different
 	branch.
 +
-Use '-o master' for continuing an import that was initially done by
+Use `-o master` for continuing an import that was initially done by
 the old cvs2git tool.
 
 -i::
@@ -91,7 +91,7 @@ the old cvs2git tool.
 	not create them if they do not exist.
 
 -k::
-	Kill keywords: will extract files with '-kk' from the CVS archive
+	Kill keywords: will extract files with `-kk` from the CVS archive
 	to avoid noisy changesets. Highly recommended, but off by default
 	to preserve compatibility with early imported trees.
 
@@ -103,7 +103,7 @@ the old cvs2git tool.
 
 -p <options-for-cvsps>::
 	Additional options for cvsps.
-	The options `-u` and '-A' are implicit and should not be used here.
+	The options `-u` and `-A` are implicit and should not be used here.
 +
 If you need to pass multiple options, separate them with a comma.
 
@@ -158,7 +158,7 @@ all along.  If a time zone is specified, GIT_AUTHOR_DATE will
 have the corresponding offset applied.
 +
 For convenience, this data is saved to `$GIT_DIR/cvs-authors`
-each time the '-A' option is provided and read from that same
+each time the `-A` option is provided and read from that same
 file each time 'git cvsimport' is run.
 +
 It is not recommended to use this feature if you intend to
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 1b1c71ad9d..955bae46c9 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -119,7 +119,7 @@ for example:
 ------
 You can use the 'htpasswd' facility that comes with Apache to make these
 files, but Apache's MD5 crypt method differs from the one used by most C
-library's crypt() function, so don't use the -m option.
+library's crypt() function, so don't use the `-m` option.
 
 Alternatively you can produce the password with perl's crypt() operator:
 -----
@@ -312,7 +312,7 @@ ENVIRONMENT
 These variables obviate the need for command-line options in some
 circumstances, allowing easier restricted usage through git-shell.
 
-GIT_CVSSERVER_BASE_PATH takes the place of the argument to --base-path.
+GIT_CVSSERVER_BASE_PATH takes the place of the argument to `--base-path`.
 
 GIT_CVSSERVER_ROOT specifies a single-directory whitelist. The
 repository must still be configured to allow access through
@@ -361,7 +361,7 @@ All the operations required for normal use are supported, including
 checkout, diff, status, update, log, add, remove, commit.
 
 Most CVS command arguments that read CVS tags or revision numbers
-(typically -r) work, and also support any git refspec
+(typically `-r`) work, and also support any git refspec
 (tag, branch, commit ID, etc).
 However, CVS revision numbers for non-default branches are not well
 emulated, and cvs log does not show tags or branches at
@@ -374,7 +374,7 @@ As described elsewhere on this page, the "module" parameter
 of cvs checkout is interpreted as a branch name, and it becomes
 the main branch.  It remains the main branch for a given sandbox
 even if you temporarily make another branch sticky with
-cvs update -r.  Alternatively, the -r argument can indicate
+cvs update -r.  Alternatively, the `-r` argument can indicate
 some other branch to actually checkout, even though the module
 is still the "main" branch.  Tradeoffs (as currently
 implemented): Each new "module" creates a new database on disk with
@@ -385,7 +385,7 @@ many operations, like cvs update.
 
 If you want to refer to a git refspec that has characters that are
 not allowed by CVS, you have two options.  First, it may just work
-to supply the git refspec directly to the appropriate CVS -r argument;
+to supply the git refspec directly to the appropriate CVS `-r` argument;
 some CVS clients don't seem to do much sanity checking of the argument.
 Second, if that fails, you can use a special character escape mechanism
 that only uses characters that are valid in CVS tags.  A sequence
@@ -415,7 +415,7 @@ Alternatively, if `gitcvs.usecrlfattr` config is not enabled
 or the attributes do not allow automatic detection for a filename, then
 the server uses the `gitcvs.allBinary` config for the default setting.
 If `gitcvs.allBinary` is set, then file not otherwise
-specified will default to '-kb' mode. Otherwise the `-k` mode
+specified will default to `-kb` mode. Otherwise the `-k` mode
 is left blank. But if `gitcvs.allBinary` is set to "guess", then
 the correct `-k` mode will be guessed based on the contents of
 the file.
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index fdc28c041c..2794a2d0c1 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -55,14 +55,14 @@ OPTIONS
 --base-path=<path>::
 	Remap all the path requests as relative to the given path.
 	This is sort of "Git root" - if you run 'git daemon' with
-	'--base-path=/srv/git' on example.com, then if you later try to pull
+	`--base-path=/srv/git` on example.com, then if you later try to pull
 	'git://example.com/hello.git', 'git daemon' will interpret the path
 	as `/srv/git/hello.git`.
 
 --base-path-relaxed::
-	If --base-path is enabled and repo lookup fails, with this option
+	If `--base-path` is enabled and repo lookup fails, with this option
 	'git daemon' will attempt to lookup without prefixing the base path.
-	This is useful for switching to --base-path usage, while still
+	This is useful for switching to `--base-path` usage, while still
 	allowing the old paths.
 
 --interpolated-path=<pathtemplate>::
@@ -81,16 +81,16 @@ OPTIONS
 	do not have the 'git-daemon-export-ok' file.
 
 --inetd::
-	Have the server run as an inetd service. Implies --syslog (may be
+	Have the server run as an inetd service. Implies `--syslog` (may be
 	overridden with `--log-destination=`).
-	Incompatible with --detach, --port, --listen, --user and --group
+	Incompatible with `--detach`, `--port`, `--listen`, `--user` and `--group`
 	options.
 
 --listen=<host_or_ipaddr>::
 	Listen on a specific IP address or hostname.  IP addresses can
 	be either an IPv4 address or an IPv6 address if supported.  If IPv6
-	is not supported, then --listen=hostname is also not supported and
-	--listen must be given an IPv4 address.
+	is not supported, then `--listen=hostname` is also not supported and
+	`--listen` must be given an IPv4 address.
 	Can be given more than once.
 	Incompatible with `--inetd` option.
 
@@ -116,7 +116,7 @@ OPTIONS
 
 --log-destination=<destination>::
 	Send log messages to the specified destination.
-	Note that this option does not imply --verbose,
+	Note that this option does not imply `--verbose`,
 	thus by default only error conditions will be logged.
 	The <destination> must be one of:
 +
@@ -154,7 +154,7 @@ otherwise `stderr`.
 	old connections to time out.
 
 --detach::
-	Detach from the shell. Implies --syslog.
+	Detach from the shell. Implies `--syslog`.
 
 --pid-file=<file>::
 	Save the process id in 'file'.  Ignored when the daemon
@@ -200,7 +200,7 @@ Git configuration files in that directory are readable by `<user>`.
 	is more convenient for clients, but may leak information about
 	the existence of unexported repositories.  When informative
 	errors are not enabled, all errors report "access denied" to the
-	client. The default is --no-informative-errors.
+	client. The default is `--no-informative-errors`.
 
 --access-hook=<path>::
 	Every time a client connects, first run an external command
@@ -219,7 +219,7 @@ it declines the service.
 
 <directory>::
 	A directory to add to the whitelist of allowed directories. Unless
-	--strict-paths is specified this will also include subdirectories
+	`--strict-paths` is specified this will also include subdirectories
 	of each named directory.
 
 SERVICES
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index a88f6ae2c6..a3f015743b 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -22,9 +22,9 @@ abbreviated object name of the most recent commit. The result
 is a "human-readable" object name which can also be used to
 identify the commit to other git commands.
 
-By default (without --all or --tags) `git describe` only shows
+By default (without `--all` or `--tags`) `git describe` only shows
 annotated tags.  For more information about creating annotated tags
-see the -a and -s options to linkgit:git-tag[1].
+see the `-a` and `-s` options to linkgit:git-tag[1].
 
 If the given object refers to a blob, it will be described
 as `<commit-ish>:<path>`, such that the blob can be found
@@ -60,7 +60,7 @@ OPTIONS
 --contains::
 	Instead of finding the tag that predates the commit, find
 	the tag that comes after the commit, and thus contains it.
-	Automatically implies --tags.
+	Automatically implies `--tags`.
 
 --abbrev=<n>::
 	Instead of using the default 7 hexadecimal digits as the
@@ -77,7 +77,7 @@ OPTIONS
 
 --exact-match::
 	Only output exact matches (a tag directly references the
-	supplied commit).  This is a synonym for --candidates=0.
+	supplied commit).  This is a synonym for `--candidates=0`.
 
 --debug::
 	Verbosely display information about the searching strategy
@@ -110,9 +110,9 @@ OPTIONS
 	excluding respectively "refs/heads/" and "refs/remotes/" prefix;
 	references of other types are never considered. If given multiple times,
 	a list of patterns will be accumulated and tags matching any of the
-	patterns will be excluded. When combined with --match a tag will be
-	considered when it matches at least one --match pattern and does not
-	match any of the --exclude patterns. Use `--no-exclude` to clear and
+	patterns will be excluded. When combined with `--match` a tag will be
+	considered when it matches at least one `--match` pattern and does not
+	match any of the `--exclude` patterns. Use `--no-exclude` to clear and
 	reset the list of patterns.
 
 --always::
@@ -150,7 +150,7 @@ Doing a 'git describe' on a tag-name will just show the tag name:
 	[torvalds@g5 git]$ git describe v1.0.4
 	v1.0.4
 
-With --all, the command can use branch heads as references, so
+With `--all`, the command can use branch heads as references, so
 the output shows the reference path as well:
 
 	[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
@@ -159,7 +159,7 @@ the output shows the reference path as well:
 	[torvalds@g5 git]$ git describe --all --abbrev=4 HEAD^
 	heads/lt/describe-7-g975b
 
-With --abbrev set to 0, the command can be used to find the
+With `--abbrev` set to 0, the command can be used to find the
 closest tagname without any suffix:
 
 	[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 2fc24c542f..b9225cd824 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -18,7 +18,7 @@ DESCRIPTION
 Compares the content and mode of the blobs found via two tree objects.
 
 If there is only one <tree-ish> given, the commit is compared with its parents
-(see --stdin below).
+(see `--stdin` below).
 
 Note that 'git diff-tree' can use the tree encapsulated in a commit object.
 
@@ -37,7 +37,7 @@ include::diff-options.txt[]
         recurse into sub-trees
 
 -t::
-	show tree entry itself as well as subtrees.  Implies -r.
+	show tree entry itself as well as subtrees.  Implies `-r`.
 
 --root::
 	When `--root` is specified the initial commit will be shown as a big
@@ -113,7 +113,7 @@ include::pretty-options.txt[]
 --combined-all-paths::
 	This flag causes combined diffs (used for merge commits) to
 	list the name of the file from all parents.  It thus only has
-	effect when -c or --cc are specified, and is likely only
+	effect when `-c` or `--cc` are specified, and is likely only
 	useful if filename changes are detected (i.e. when either
 	rename or copy detection have been requested).
 
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 7f4c8a8ce7..9f4b46c910 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -48,9 +48,9 @@ files on disk.
 	do not give <commit>, it defaults to HEAD.
 	If HEAD does not exist (e.g. unborn branches) and
 	<commit> is not given, it shows all staged changes.
-	--staged is a synonym of --cached.
+	`--staged` is a synonym of `--cached`.
 +
-If --merge-base is given, instead of using <commit>, use the merge base
+If `--merge-base` is given, instead of using <commit>, use the merge base
 of <commit> and HEAD.  `git diff --merge-base A` is equivalent to
 `git diff $(git merge-base A HEAD)`.
 
@@ -67,7 +67,7 @@ of <commit> and HEAD.  `git diff --merge-base A` is equivalent to
 	This is to view the changes between two arbitrary
 	<commit>.
 +
-If --merge-base is given, use the merge base of the two commits for the
+If `--merge-base` is given, use the merge base of the two commits for the
 "before" side.  `git diff --merge-base A B` is equivalent to
 `git diff $(git merge-base A B) B`.
 
diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
index 1978dbdc6a..a1c02918f9 100644
--- a/Documentation/git-fast-export.txt
+++ b/Documentation/git-fast-export.txt
@@ -67,14 +67,14 @@ produced incorrect results if you gave these options.
 	have been completed, or to save the marks table across
 	incremental runs.  As <file> is only opened and truncated
 	at completion, the same path can also be safely given to
-	--import-marks.
+	`--import-marks`.
 	The file will not be written if no new object has been
 	marked/exported.
 
 --import-marks=<file>::
 	Before processing any input, load the marks specified in
 	<file>.  The input file must exist, must be readable, and
-	must use the same format as produced by --export-marks.
+	must use the same format as produced by `--export-marks`.
 
 --mark-tags::
 	In addition to labelling blobs and commits with mark ids, also
@@ -86,7 +86,7 @@ produced incorrect results if you gave these options.
 	identifiers.
 +
 Any commits (or tags) that have already been marked will not be
-exported again.  If the backend uses a similar --import-marks file,
+exported again.  If the backend uses a similar `--import-marks` file,
 this allows for incremental bidirectional exporting of the repository
 by keeping the marks the same across runs.
 
@@ -130,7 +130,7 @@ by keeping the marks the same across runs.
 	and will make master{tilde}4 no longer have master{tilde}5 as
 	a parent (though both the old master{tilde}4 and new
 	master{tilde}4 will have all the same files).  Use
-	--reference-excluded-parents to instead have the stream
+	`--reference-excluded-parents` to instead have the stream
 	refer to commits in the excluded range of history by their
 	sha1sum.  Note that the resulting stream can only be used by a
 	repository which already contains the necessary parent
@@ -160,7 +160,7 @@ by keeping the marks the same across runs.
 	to export.  For example, `master~10..master` causes the
 	current master reference to be exported along with all objects
 	added since its 10th ancestor commit and (unless the
-	--reference-excluded-parents option is specified) all files
+	`--reference-excluded-parents` option is specified) all files
 	common to master{tilde}9 and master{tilde}10.
 
 EXAMPLES
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 39cfa05b28..ff67238633 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -40,7 +40,7 @@ OPTIONS
 	not contain the old commit).
 
 --quiet::
-	Disable the output shown by --stats, making fast-import usually
+	Disable the output shown by `--stats`, making fast-import usually
 	be silent when it is successful.  However, if the import stream
 	has directives intended to show user output (e.g. `progress`
 	directives), the corresponding messages will still be shown.
@@ -49,7 +49,7 @@ OPTIONS
 	Display some basic statistics about the objects fast-import has
 	created, the packfiles they were stored into, and the
 	memory used by fast-import during this run.  Showing this output
-	is currently the default, but can be disabled with --quiet.
+	is currently the default, but can be disabled with `--quiet`.
 
 --allow-unsafe-features::
 	Many command-line options can be provided as part of the
@@ -97,23 +97,23 @@ Locations of Marks Files
 	have been completed, or to save the marks table across
 	incremental runs.  As <file> is only opened and truncated
 	at checkpoint (or completion) the same path can also be
-	safely given to --import-marks.
+	safely given to `--import-marks`.
 
 --import-marks=<file>::
 	Before processing any input, load the marks specified in
 	<file>.  The input file must exist, must be readable, and
-	must use the same format as produced by --export-marks.
+	must use the same format as produced by `--export-marks`.
 	Multiple options may be supplied to import more than one
 	set of marks.  If a mark is defined to different values,
 	the last file wins.
 
 --import-marks-if-exists=<file>::
-	Like --import-marks but instead of erroring out, silently
+	Like `--import-marks` but instead of erroring out, silently
 	skips the file if it does not exist.
 
 --[no-]relative-marks::
-	After specifying --relative-marks the paths specified
-	with --import-marks= and --export-marks= are relative
+	After specifying `--relative-marks` the paths specified
+	with `--import-marks`= and `--export-marks`= are relative
 	to an internal directory in the current repository.
 	In git-fast-import this means that the paths are relative
 	to the .git/info/fast-import directory. However, other
@@ -217,8 +217,8 @@ fast-forward update, fast-import will skip updating that ref and instead
 prints a warning message.  fast-import will always attempt to update all
 branch refs, and does not stop on the first failure.
 
-Branch updates can be forced with --force, but it's recommended that
-this only be used on an otherwise quiet repository.  Using --force
+Branch updates can be forced with `--force`, but it's recommended that
+this only be used on an otherwise quiet repository.  Using `--force`
 is not necessary for an initial import into an empty repository.
 
 
@@ -269,11 +269,11 @@ Date Formats
 ~~~~~~~~~~~~
 The following date formats are supported.  A frontend should select
 the format it will use for this import by passing the format name
-in the --date-format=<fmt> command-line option.
+in the `--date-format`=<fmt> command-line option.
 
 `raw`::
 	This is the Git native format and is `<time> SP <offutc>`.
-	It is also fast-import's default format, if --date-format was
+	It is also fast-import's default format, if `--date-format` was
 	not specified.
 +
 The time of the event is specified by `<time>` as the number of
@@ -381,7 +381,7 @@ and control the current import process.  More detailed discussion
 
 `alias`::
 	Record that a mark refers to a given object without first
-	creating any new object.  Using --import-marks and referring
+	creating any new object.  Using `--import-marks` and referring
 	to missing marks will cause fast-import to fail, so aliases
 	can provide a way to set otherwise pruned commits to a valid
 	value (e.g. the nearest non-pruned ancestor).
@@ -501,7 +501,7 @@ the email address from the other fields in the line.  Note that
 of bytes, except `LT`, `GT` and `LF`.  `<name>` is typically UTF-8 encoded.
 
 The time of the change is specified by `<when>` using the date format
-that was selected by the --date-format=<fmt> command-line option.
+that was selected by the `--date-format`=<fmt> command-line option.
 See ``Date Formats'' above for the set of supported formats, and
 their syntax.
 
@@ -989,7 +989,7 @@ save out all current branch refs, tags and marks.
 ....
 
 Note that fast-import automatically switches packfiles when the current
-packfile reaches --max-pack-size, or 4 GiB, whichever limit is
+packfile reaches `--max-pack-size`, or 4 GiB, whichever limit is
 smaller.  During an automatic packfile switch fast-import does not update
 the branch refs, tags or marks.
 
@@ -1152,10 +1152,10 @@ force::
 
 import-marks::
 import-marks-if-exists::
-	Like --import-marks except in two respects: first, only one
+	Like `--import-marks` except in two respects: first, only one
 	"feature import-marks" or "feature import-marks-if-exists"
-	command is allowed per stream; second, an --import-marks=
-	or --import-marks-if-exists command-line option overrides
+	command is allowed per stream; second, an `--import-marks=`
+	or `--import-marks-if-exists` command-line option overrides
 	any of these "feature" commands in the stream; third,
 	"feature import-marks-if-exists" like a corresponding
 	command-line option silently skips a nonexistent file.
@@ -1346,7 +1346,7 @@ users of fast-import, and are offered here as suggestions.
 Use One Mark Per Commit
 ~~~~~~~~~~~~~~~~~~~~~~~
 When doing a repository conversion, use a unique mark per commit
-(`mark :<n>`) and supply the --export-marks option on the command
+(`mark :<n>`) and supply the `--export-marks` option on the command
 line.  fast-import will dump a file which lists every mark and the Git
 object SHA-1 that corresponds to it.  If the frontend can tie
 the marks back to the source repository, it is easy to verify the
@@ -1411,7 +1411,7 @@ even for considerably large projects (100,000+ commits).
 
 However repacking the repository is necessary to improve data
 locality and access performance.  It can also take hours on extremely
-large projects (especially if -f and a large --window parameter is
+large projects (especially if `-f` and a large `--window` parameter is
 used).  Since repacking is safe to run alongside readers and writers,
 run the repack in the background and let it finish when it finishes.
 There is no reason to wait to explore your new Git project!
@@ -1425,7 +1425,7 @@ Repacking Historical Data
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 If you are repacking very old imported data (e.g. older than the
 last year), consider expending some extra CPU time and supplying
---window=50 (or higher) when you run 'git repack'.
+`--window=50` (or higher) when you run 'git repack'.
 This will take longer, but will also produce a smaller packfile.
 You only need to expend the effort once, and everyone using your
 project will benefit from the smaller repository.
@@ -1534,7 +1534,7 @@ branch, their in-memory storage size can grow to a considerable size
 fast-import automatically moves active branches to inactive status based on
 a simple least-recently-used algorithm.  The LRU chain is updated on
 each `commit` command.  The maximum number of active branches can be
-increased or decreased on the command line with --active-branches=.
+increased or decreased on the command line with `--active-branches`=.
 
 per active tree
 ~~~~~~~~~~~~~~~
diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
index c975884793..88c2b9d426 100644
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -80,7 +80,7 @@ be in a separate packet, and the list must end with a flush packet.
 	the things up in .bash_profile).
 
 --exec=<git-upload-pack>::
-	Same as --upload-pack=<git-upload-pack>.
+	Same as `--upload-pack`=<git-upload-pack>.
 
 --depth=<n>::
 	Limit fetching to ancestor-chains not longer than n.
@@ -97,7 +97,7 @@ be in a separate packet, and the list must end with a flush packet.
 	This option can be specified multiple times.
 
 --deepen-relative::
-	Argument --depth specifies the number of commits from the
+	Argument `--depth` specifies the number of commits from the
 	current shallow boundary instead of from the tip of each
 	remote branch history.
 
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 9067c2079e..85b073a61a 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -25,7 +25,7 @@ of <refspec> below for ways to control this behavior).
 By default, any tag that points into the histories being fetched is
 also fetched; the effect is to fetch tags that
 point at branches that you are interested in.  This default behavior
-can be changed by using the --tags or --no-tags options or by
+can be changed by using the `--tags` or `--no-tags` options or by
 configuring remote.<name>.tagOpt.  By using a refspec that fetches tags
 explicitly, you can fetch tags that do not point into branches you
 are interested in as well.
@@ -204,7 +204,7 @@ representing the status of a single ref. Each line is of the form:
  <flag> <summary> <from> -> <to> [<reason>]
 -------------------------------
 
-The status of up-to-date refs is shown only if the --verbose option is
+The status of up-to-date refs is shown only if the `--verbose` option is
 used.
 
 In compact output mode, specified with configuration variable
@@ -287,7 +287,7 @@ include::transfer-data-leaks.txt[]
 
 BUGS
 ----
-Using --recurse-submodules can only fetch new commits in already checked
+Using `--recurse-submodules` can only fetch new commits in already checked
 out submodules right now. When e.g. upstream added a new submodule in the
 just fetched commits of the superproject the submodule itself cannot be
 fetched, making it impossible to check out that submodule later without
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 62e482a95e..2de3511459 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -133,8 +133,8 @@ OPTIONS
 	It will receive the parent string on stdin and shall output
 	the new parent string on stdout.  The parent string is in
 	the format described in linkgit:git-commit-tree[1]: empty for
-	the initial commit, "-p parent" for a normal commit and
-	"-p parent1 -p parent2 -p parent3 ..." for a merge commit.
+	the initial commit, `-p parent` for a normal commit and
+	`-p parent1 -p parent2 -p parent3 ...` for a merge commit.
 
 --msg-filter <command>::
 	This is the filter for rewriting the commit messages.
@@ -170,7 +170,7 @@ and that makes no change to the tree.
 	tag name is expected on standard output.
 +
 The original tags are not deleted, but can be overwritten;
-use "--tag-name-filter cat" to simply update the tags.  In this
+use `--tag-name-filter cat` to simply update the tags.  In this
 case, be very careful and make sure you have the old tags
 backed up in case the conversion has run afoul.
 +
@@ -598,12 +598,12 @@ with:
   sensitive files and others which don't.  This comes about in
   multiple different ways:
 
-  ** the default to only doing a partial history rewrite ('--all' is not
+  ** the default to only doing a partial history rewrite (`--all` is not
      the default and few examples show it)
 
   ** the fact that there's no automatic post-run cleanup
 
-  ** the fact that --tag-name-filter (when used to rename tags) doesn't
+  ** the fact that `--tag-name-filter` (when used to rename tags) doesn't
      remove the old tags but just adds new ones with the new name
 
   ** the fact that little educational information is provided to inform
@@ -623,15 +623,15 @@ with:
      git-filter-branch command.  (The backup in refs/original/ is not a
      real backup; it dereferences tags first.)
 
-  ** Running git-filter-branch with either --tags or --all in your
+  ** Running git-filter-branch with either `--tags` or `--all` in your
      <rev-list options>.  In order to retain annotated tags as
-     annotated, you must use --tag-name-filter (and must not have
+     annotated, you must use `--tag-name-filter` (and must not have
      restored from refs/original/ in a previously botched rewrite).
 
 * Any commit messages that specify an encoding will become corrupted
   by the rewrite; git-filter-branch ignores the encoding, takes the
   original bytes, and feeds it to commit-tree without telling it the
-  proper encoding.  (This happens whether or not --msg-filter is
+  proper encoding.  (This happens whether or not `--msg-filter` is
   used.)
 
 * Commit messages (even if they are all UTF-8) by default become
@@ -650,21 +650,21 @@ with:
   dependencies (node_modules or similar) which couldn't have ever been
   functional since it's missing some files.)
 
-* If --prune-empty isn't specified, then the filtering process can
+* If `--prune-empty` isn't specified, then the filtering process can
   create hoards of confusing empty commits
 
-* If --prune-empty is specified, then intentionally placed empty
+* If `--prune-empty` is specified, then intentionally placed empty
   commits from before the filtering operation are also pruned instead
   of just pruning commits that became empty due to filtering rules.
 
-* If --prune-empty is specified, sometimes empty commits are missed
+* If `--prune-empty` is specified, sometimes empty commits are missed
   and left around anyway (a somewhat rare bug, but it happens...)
 
 * A minor issue, but users who have a goal to update all names and
-  emails in a repository may be led to --env-filter which will only
+  emails in a repository may be led to `--env-filter` which will only
   update authors and committers, missing taggers.
 
-* If the user provides a --tag-name-filter that maps multiple tags to
+* If the user provides a `--tag-name-filter` that maps multiple tags to
   the same name, no warning or error is provided; git-filter-branch
   simply overwrites each tag in some undocumented pre-defined order
   resulting in only one tag at the end.  (A git-filter-branch
diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt
index 6793d8fc05..9004861eae 100644
--- a/Documentation/git-fmt-merge-msg.txt
+++ b/Documentation/git-fmt-merge-msg.txt
@@ -36,7 +36,7 @@ OPTIONS
 	merged.
 
 --[no-]summary::
-	Synonyms to --log and --no-log; these are deprecated and will be
+	Synonyms to `--log` and `--no-log`; these are deprecated and will be
 	removed in the future.
 
 -m <message>::
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 2ae2478de7..e035edf11d 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -40,7 +40,7 @@ OPTIONS
 --sort=<key>::
 	A field name to sort on.  Prefix `-` to sort in
 	descending order of the value.  When unspecified,
-	`refname` is used.  You may use the --sort=<key> option
+	`refname` is used.  You may use the `--sort=<key>` option
 	multiple times, in which case the last key becomes the primary
 	key.
 
@@ -309,7 +309,7 @@ Ref: %(*refname)
 
 
 A simple example showing the use of shell eval on the output,
-demonstrating the use of --shell.  List the prefixes of all heads:
+demonstrating the use of `--shell`.  List the prefixes of all heads:
 ------------
 #!/bin/sh
 
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 911da181a1..ca500ba72c 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -238,8 +238,8 @@ populated with placeholder text.
 	`--subject-prefix` option) has ` v<n>` appended to it.  E.g.
 	`--reroll-count=4` may produce `v4-0001-add-makefile.patch`
 	file that has "Subject: [PATCH v4 1/20] Add makefile" in it.
-	`<n>` does not have to be an integer (e.g. "--reroll-count=4.4",
-	or "--reroll-count=4rev2" are allowed), but the downside of
+	`<n>` does not have to be an integer (e.g. `--reroll-count=4.4`,
+	or `--reroll-count=4rev2` are allowed), but the downside of
 	using such a reroll-count is that the range-diff/interdiff
 	with the previous version does not state exactly which
 	version the new interation is compared against.
@@ -346,7 +346,7 @@ set.
 	number.
 
 --signature-file=<file>::
-	Works just like --signature except the signature is read from a file.
+	Works just like `--signature` except the signature is read from a file.
 
 --suffix=.<sfx>::
 	Instead of using `.patch` as the suffix for generated
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index bd596619c0..e932c75181 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -25,7 +25,7 @@ OPTIONS
 +
 If no objects are given, 'git fsck' defaults to using the
 index file, all SHA-1 references in `refs` namespace, and all reflogs
-(unless --no-reflogs is given) as heads.
+(unless `--no-reflogs` is given) as heads.
 
 --unreachable::
 	Print out objects that exist but that aren't reachable from any
@@ -59,7 +59,7 @@ index file, all SHA-1 references in `refs` namespace, and all reflogs
 	and in packed Git archives found in $GIT_DIR/objects/pack
 	and corresponding pack subdirectories in alternate
 	object pools.  This is now default; you can turn it off
-	with --no-full.
+	with `--no-full`.
 
 --connectivity-only::
 	Check only the connectivity of reachable objects, making sure
@@ -100,7 +100,7 @@ care about this output and want to speed it up further.
 --[no-]progress::
 	Progress status is reported on the standard error stream by
 	default when it is attached to a terminal, unless
-	--no-progress or --verbose is specified. --progress forces
+	`--no-progress` or `--verbose` is specified. `--progress` forces
 	progress status even if the standard error stream is not
 	directed to a terminal.
 
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 853967dea0..9d27c3a41e 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -57,9 +57,9 @@ be performed as well.
 --prune=<date>::
 	Prune loose objects older than date (default is 2 weeks ago,
 	overridable by the config variable `gc.pruneExpire`).
-	--prune=now prunes loose objects regardless of their age and
+	`--prune=now` prunes loose objects regardless of their age and
 	increases the risk of corruption if another process is writing to
-	the repository concurrently; see "NOTES" below. --prune is on by
+	the repository concurrently; see "NOTES" below. `--prune` is on by
 	default.
 
 --no-prune::
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 4e0ba8234a..84102cc596 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -66,7 +66,7 @@ grep.fullName::
 	If set to true, enable `--full-name` option by default.
 
 grep.fallbackToNoIndex::
-	If set to true, fall back to git grep --no-index if git grep
+	If set to true, fall back to git grep `--no-index` if git grep
 	is executed outside of a git repository.  Defaults to false.
 
 
@@ -123,7 +123,7 @@ OPTIONS
 	levels of directories. A value of -1 means no limit.
 	This option is ignored if <pathspec> contains active wildcards.
 	In other words if "a*" matches a directory named "a*",
-	"*" is matched literally so --max-depth is still effective.
+	"*" is matched literally so `--max-depth` is still effective.
 
 -r::
 --recursive::
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index 44fe8860b3..a19f275f60 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -98,16 +98,16 @@ variable will be checked. The following values are supported for this
 variable; they make 'git help' behave as their corresponding command-
 line option:
 
-* "man" corresponds to '-m|--man',
-* "info" corresponds to '-i|--info',
-* "web" or "html" correspond to '-w|--web'.
+* "man" corresponds to `-m`|`--man`,
+* "info" corresponds to `-i`|`--info`,
+* "web" or "html" correspond to `-w`|`--web`.
 
 help.browser, web.browser and browser.<tool>.path
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The `help.browser`, `web.browser` and `browser.<tool>.path` will also
 be checked if the 'web' format is chosen (either by command-line
-option or configuration variable). See '-w|--web' in the OPTIONS
+option or configuration variable). See `-w`|`--web` in the OPTIONS
 section above and linkgit:git-web{litdd}browse[1].
 
 man.viewer
diff --git a/Documentation/git-http-fetch.txt b/Documentation/git-http-fetch.txt
index 9fa17b60e4..969e553e4a 100644
--- a/Documentation/git-http-fetch.txt
+++ b/Documentation/git-http-fetch.txt
@@ -47,7 +47,7 @@ commit-id::
 	URL and uses index-pack to generate corresponding .idx and .keep files.
 	The hash is used to determine the name of the temporary file and is
 	arbitrary. The output of index-pack is printed to stdout. Requires
-	--index-pack-args.
+	`--index-pack-args`.
 
 --index-pack-args=<args>::
 	For internal use only. The command to run on the contents of the
diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt
index ea03a4eeb0..5dd4d2b63a 100644
--- a/Documentation/git-http-push.txt
+++ b/Documentation/git-http-push.txt
@@ -44,7 +44,7 @@ OPTIONS
 -d::
 -D::
 	Remove <ref> from remote repository.  The specified branch
-	cannot be the remote HEAD.  If -d is specified the following
+	cannot be the remote HEAD.  If `-d` is specified the following
 	other conditions must also be met:
 
 	- Remote HEAD must resolve to an object that exists locally
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
index 7fa74b9e79..bde1cf4a5c 100644
--- a/Documentation/git-index-pack.txt
+++ b/Documentation/git-index-pack.txt
@@ -49,7 +49,7 @@ OPTIONS
 	<pack-file> is not specified, the pack is written to
 	objects/pack/ directory of the current Git repository with
 	a default name determined from the pack content.  If
-	<pack-file> is not specified consider using --keep to
+	<pack-file> is not specified consider using `--keep` to
 	prevent a race condition between this process and
 	'git repack'.
 
@@ -57,18 +57,18 @@ OPTIONS
 	Fix a "thin" pack produced by `git pack-objects --thin` (see
 	linkgit:git-pack-objects[1] for details) by adding the
 	excluded objects the deltified objects are based on to the
-	pack. This option only makes sense in conjunction with --stdin.
+	pack. This option only makes sense in conjunction with `--stdin`.
 
 --keep::
 	Before moving the index into its final destination
 	create an empty .keep file for the associated pack file.
-	This option is usually necessary with --stdin to prevent a
+	This option is usually necessary with `--stdin` to prevent a
 	simultaneous 'git repack' process from deleting
 	the newly constructed pack and index before refs can be
 	updated to use objects contained in the pack.
 
 --keep=<msg>::
-	Like --keep create a .keep file before moving the index into
+	Like `--keep` create a .keep file before moving the index into
 	its final destination, but rather than creating an empty file
 	place '<msg>' followed by an LF into the .keep file.  The '<msg>'
 	message can later be searched for within all .keep files to
@@ -112,7 +112,7 @@ name of the pack/idx file (see "Notes").
 	the current repository (set by `extensions.objectFormat`), or 'sha1' if no
 	value is set or outside a repository.
 +
-This option cannot be used with --stdin.
+This option cannot be used with `--stdin`.
 +
 include::object-format-disclaimer.txt[]
 
@@ -120,7 +120,7 @@ NOTES
 -----
 
 Once the index has been created, the hash that goes into the name of
-the pack/idx file is printed to stdout. If --stdin was
+the pack/idx file is printed to stdout. If `--stdin` was
 also used then this is prefixed by either "pack\t", or "keep\t" if a
 new .keep file was successfully created. This is useful to remove a
 .keep file used as a lock to prevent the race with 'git repack'
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index b611d80697..a3f061517d 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -35,7 +35,7 @@ directory is used.
 Running 'git init' in an existing repository is safe. It will not
 overwrite things that are already there. The primary reason for
 rerunning 'git init' is to pick up newly added templates (or to move
-the repository to another place if --separate-git-dir is given).
+the repository to another place if `--separate-git-dir` is given).
 
 OPTIONS
 -------
diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt
index 96ec6499f0..4288e5405c 100644
--- a/Documentation/git-interpret-trailers.txt
+++ b/Documentation/git-interpret-trailers.txt
@@ -87,27 +87,27 @@ OPTIONS
 --where <placement>::
 --no-where::
 	Specify where all new trailers will be added.  A setting
-	provided with '--where' overrides all configuration variables
-	and applies to all '--trailer' options until the next occurrence of
-	'--where' or '--no-where'. Possible values are `after`, `before`,
+	provided with `--where` overrides all configuration variables
+	and applies to all `--trailer` options until the next occurrence of
+	`--where` or `--no-where`. Possible values are `after`, `before`,
 	`end` or `start`.
 
 --if-exists <action>::
 --no-if-exists::
 	Specify what action will be performed when there is already at
 	least one trailer with the same <token> in the message.  A setting
-	provided with '--if-exists' overrides all configuration variables
-	and applies to all '--trailer' options until the next occurrence of
-	'--if-exists' or '--no-if-exists'. Possible actions are `addIfDifferent`,
+	provided with `--if-exists` overrides all configuration variables
+	and applies to all `--trailer` options until the next occurrence of
+	`--if-exists` or `--no-if-exists`. Possible actions are `addIfDifferent`,
 	`addIfDifferentNeighbor`, `add`, `replace` and `doNothing`.
 
 --if-missing <action>::
 --no-if-missing::
 	Specify what action will be performed when there is no other
 	trailer with the same <token> in the message.  A setting
-	provided with '--if-missing' overrides all configuration variables
-	and applies to all '--trailer' options until the next occurrence of
-	'--if-missing' or '--no-if-missing'. Possible actions are `doNothing`
+	provided with `--if-missing` overrides all configuration variables
+	and applies to all `--trailer` options until the next occurrence of
+	`--if-missing` or `--no-if-missing`. Possible actions are `doNothing`
 	or `add`.
 
 --only-trailers::
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 6d11ab506b..b42f179aef 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -65,11 +65,11 @@ OPTIONS
 	name (with a trailing slash) and not its whole contents.
 
 --no-empty-directory::
-	Do not list empty directories. Has no effect without --directory.
+	Do not list empty directories. Has no effect without `--directory`.
 
 -u::
 --unmerged::
-	Show unmerged files in the output (forces --stage)
+	Show unmerged files in the output (forces `--stage`)
 
 -k::
 --killed::
@@ -111,7 +111,7 @@ OPTIONS
 	error (return 1).
 
 --with-tree=<tree-ish>::
-	When using --error-unmatch to expand the user supplied
+	When using `--error-unmatch` to expand the user supplied
 	<file> (i.e. path pattern) arguments to paths, pretend
 	that paths which were removed in the index since the
 	named <tree-ish> are still present.  Using this option
@@ -156,13 +156,13 @@ a space) at the start of each line:
 
 --recurse-submodules::
 	Recursively calls ls-files on each active submodule in the repository.
-	Currently there is only support for the --cached mode.
+	Currently there is only support for the `--cached` mode.
 
 --abbrev[=<n>]::
 	Instead of showing the full 40-byte hexadecimal object
 	lines, show the shortest prefix that is at least '<n>'
 	hexdigits long that uniquely refers the object.
-	Non default number of digits can be specified with --abbrev=<n>.
+	Non default number of digits can be specified with `--abbrev=<n>`.
 
 --debug::
 	After each line that describes a file, add more data about its
@@ -224,29 +224,29 @@ EXCLUDE PATTERNS
 
 'git ls-files' can use a list of "exclude patterns" when
 traversing the directory tree and finding files to show when the
-flags --others or --ignored are specified.  linkgit:gitignore[5]
+flags `--others` or `--ignored` are specified.  linkgit:gitignore[5]
 specifies the format of exclude patterns.
 
 These exclude patterns come from these places, in order:
 
-  1. The command-line flag --exclude=<pattern> specifies a
+  1. The command-line flag `--exclude=<pattern>` specifies a
      single pattern.  Patterns are ordered in the same order
      they appear in the command line.
 
-  2. The command-line flag --exclude-from=<file> specifies a
+  2. The command-line flag `--exclude-from=<file>` specifies a
      file containing a list of patterns.  Patterns are ordered
      in the same order they appear in the file.
 
-  3. The command-line flag --exclude-per-directory=<name> specifies
+  3. The command-line flag `--exclude-per-directory=<name>` specifies
      a name of the file in each directory 'git ls-files'
      examines, normally `.gitignore`.  Files in deeper
      directories take precedence.  Patterns are ordered in the
      same order they appear in the files.
 
-A pattern specified on the command line with --exclude or read
-from the file specified with --exclude-from is relative to the
+A pattern specified on the command line with `--exclude` or read
+from the file specified with `--exclude-from` is relative to the
 top of the directory tree.  A pattern read from a file specified
-by --exclude-per-directory is relative to the directory that the
+by `--exclude-per-directory` is relative to the directory that the
 pattern file appears in.
 
 SEE ALSO
diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
index 492e573856..4cb4e2fd5d 100644
--- a/Documentation/git-ls-remote.txt
+++ b/Documentation/git-ls-remote.txt
@@ -87,7 +87,7 @@ OPTIONS
 
 <refs>...::
 	When unspecified, all references, after filtering done
-	with --heads and --tags, are shown.  When <refs>... are
+	with `--heads` and `--tags`, are shown.  When <refs>... are
 	specified, only references matching the given patterns
 	are displayed.
 
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index db02d6d79a..6ed9030c1e 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -31,7 +31,7 @@ in the current working directory.  Note that:
    root level (e.g. `git ls-tree -r HEAD:sub dir`) in this case, as that
    would result in asking for `sub/sub/dir` in the `HEAD` commit.
    However, the current working directory can be ignored by passing
-   --full-tree option.
+   `--full-tree` option.
 
 OPTIONS
 -------
@@ -64,7 +64,7 @@ OPTIONS
 	Instead of showing the full 40-byte hexadecimal object
 	lines, show the shortest prefix that is at least '<n>'
 	hexdigits long that uniquely refers the object.
-	Non default number of digits can be specified with --abbrev=<n>.
+	Non default number of digits can be specified with `--abbrev`=<n>.
 
 --full-name::
 	Instead of showing the path names relative to the current working
@@ -72,7 +72,7 @@ OPTIONS
 
 --full-tree::
 	Do not limit the listing to the current working directory.
-	Implies --full-name.
+	Implies `--full-name`.
 
 [<path>...]::
 	When paths are given, show them (note that this isn't really raw
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index d343f040f5..5bc2982909 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -45,7 +45,7 @@ Finally, runs of whitespace are normalized to a single ASCII space
 character.
 
 -b::
-	When -k is not in effect, all leading strings bracketed with '['
+	When `-k` is not in effect, all leading strings bracketed with '['
 	and ']' pairs are stripped.  This option limits the stripping to
 	only the pairs whose bracketed string contains the word "PATCH".
 
@@ -60,7 +60,7 @@ Note that the patch is always used as-is without charset
 conversion, even with this flag.
 
 --encoding=<encoding>::
-	Similar to -u.  But when re-coding, the charset specified here is
+	Similar to `-u`.  But when re-coding, the charset specified here is
 	used instead of the one specified by `i18n.commitEncoding` or UTF-8.
 
 -n::
diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt
index e3b2a88c4b..6e357716ec 100644
--- a/Documentation/git-mailsplit.txt
+++ b/Documentation/git-mailsplit.txt
@@ -42,7 +42,7 @@ OPTIONS
 	filenames.
 
 -f<nn>::
-	Skip the first <nn> numbers, for example if -f3 is specified,
+	Skip the first <nn> numbers, for example if `-f`3 is specified,
 	start the numbering with 0004.
 
 --keep-cr::
diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt
index 2ab84a91e5..9fdfe6a31b 100644
--- a/Documentation/git-merge-index.txt
+++ b/Documentation/git-merge-index.txt
@@ -37,7 +37,7 @@ OPTIONS
 	failure usually indicates conflicts during the merge). This is for
 	porcelains which might want to emit custom messages.
 
-If 'git merge-index' is called with multiple <file>s (or -a) then it
+If 'git merge-index' is called with multiple <file>s (or `-a`) then it
 processes them in turn only stopping if merge returns a non-zero exit
 code.
 
diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt
index 79449bf98f..b3808dcc06 100644
--- a/Documentation/git-mv.txt
+++ b/Documentation/git-mv.txt
@@ -50,7 +50,7 @@ Moving a submodule using a gitfile (which means they were cloned
 with a Git version 1.7.8 or newer) will update the gitfile and
 core.worktree setting to make the submodule work in the new location.
 It also will attempt to update the submodule.<name>.path setting in
-the linkgit:gitmodules[5] file and stage that file (unless -n is used).
+the linkgit:gitmodules[5] file and stage that file (unless `-n` is used).
 
 BUGS
 ----
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index 5cb0eb0855..99979fe55b 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -34,9 +34,9 @@ OPTIONS
 	Do not use any ref whose name matches a given shell pattern. The
 	pattern can be one of branch name, tag name or fully qualified ref
 	name. If given multiple times, a ref will be excluded when it matches
-	any of the given patterns. When used together with --refs, a ref will
-	be used as a match only when it matches at least one --refs pattern and
-	does not match any --exclude patterns. Use `--no-exclude` to clear the
+	any of the given patterns. When used together with `--refs`, a ref will
+	be used as a match only when it matches at least one `--refs` pattern and
+	does not match any `--exclude` patterns. Use `--no-exclude` to clear the
 	list of exclude patterns.
 
 --all::
@@ -45,12 +45,12 @@ OPTIONS
 --stdin::
 	Transform stdin by substituting all the 40-character SHA-1
 	hexes (say $hex) with "$hex ($rev_name)".  When used with
-	--name-only, substitute with "$rev_name", omitting $hex
+	`--name-only`, substitute with "$rev_name", omitting $hex
 	altogether.  Intended for the scripter's use.
 
 --name-only::
 	Instead of printing both the SHA-1 and the name, print only
-	the name.  If given with --tags the usual tag prefix of
+	the name.  If given with `--tags` the usual tag prefix of
 	"tags/" is also omitted from the name, matching the output
 	of `git-describe` more closely.
 
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index 0a4200674c..b0a5ab9a72 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -152,7 +152,7 @@ OPTIONS
 
 -c <object>::
 --reedit-message=<object>::
-	Like '-C', but with `-c` the editor is invoked, so that
+	Like `-C`, but with `-c` the editor is invoked, so that
 	the user can further edit the note message.
 
 --allow-empty::
@@ -251,7 +251,7 @@ When done, the user can either finalize the merge with
 'git notes merge --abort'.
 
 Users may select an automated merge strategy from among the following using
-either -s/--strategy option or configuring notes.mergeStrategy accordingly:
+either `-s`/`--strategy` option or configuring notes.mergeStrategy accordingly:
 
 "ours" automatically resolves conflicting notes in favor of the local
 version (i.e. the current notes ref).
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index f89e68b424..d9d29a5efa 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -180,7 +180,7 @@ The git commit is created relative to the current origin revision (HEAD by defau
 A parent commit is created based on the origin, and then the unshelve commit is
 created based on that.
 
-The origin revision can be changed with the "--origin" option.
+The origin revision can be changed with the `--origin` option.
 
 If the target branch in refs/remotes/p4-unshelved already exists, the old one will
 be renamed.
@@ -221,7 +221,7 @@ subsequent 'sync' operations.
 +
 By default a <ref> not starting with refs/ is treated as the
 name of a remote-tracking branch (under refs/remotes/).  This
-behavior can be modified using the --import-local option.
+behavior can be modified using the `--import-local` option.
 +
 The default <ref> is "master".
 +
@@ -265,7 +265,7 @@ Git repository:
 	Import at most 'n' changes, rather than the entire range of
 	changes included in the given revision specifier. A typical
 	usage would be use '@all' as the revision specifier, but then
-	to use '--max-changes 1000' to import only the last 1000
+	to use `--max-changes 1000` to import only the last 1000
 	revisions rather than the entire revision history.
 
 --changes-block-size <n>::
@@ -347,7 +347,7 @@ These options can be used to modify 'git p4 submit' behavior.
 
 --update-shelve CHANGELIST::
 	Update an existing shelved changelist with this commit. Implies
-	--shelve. Repeat for multiple shelved changelists.
+	`--shelve`. Repeat for multiple shelved changelists.
 
 --conflict=(ask|skip|quit)::
 	Conflicts can occur when applying a commit to p4.  When this
@@ -371,7 +371,7 @@ These options can be used to modify 'git p4 submit' behavior.
 
 --disable-p4sync::
     Disable the automatic sync of p4/master from Perforce after commits have
-    been submitted. Implies --disable-rebase. Can also be set with
+    been submitted. Implies `--disable-rebase`. Can also be set with
     git-p4.disableP4Sync. Sync with origin/master still goes ahead if possible.
 
 Hooks for submit
@@ -560,27 +560,27 @@ They all are in the 'git-p4' section.
 General variables
 ~~~~~~~~~~~~~~~~~
 git-p4.user::
-	User specified as an option to all p4 commands, with '-u <user>'.
+	User specified as an option to all p4 commands, with `-u <user>`.
 	The environment variable `P4USER` can be used instead.
 
 git-p4.password::
 	Password specified as an option to all p4 commands, with
-	'-P <password>'.
+	`-P <password>`.
 	The environment variable `P4PASS` can be used instead.
 
 git-p4.port::
 	Port specified as an option to all p4 commands, with
-	'-p <port>'.
+	`-p <port>`.
 	The environment variable `P4PORT` can be used instead.
 
 git-p4.host::
 	Host specified as an option to all p4 commands, with
-	'-h <host>'.
+	`-h <host>`.
 	The environment variable `P4HOST` can be used instead.
 
 git-p4.client::
 	Client specified as an option to all p4 commands, with
-	'-c <client>', including the client spec.
+	`-c <client>`, including the client spec.
 
 git-p4.retries::
 	Specifies the number of times to retry a p4 command (notably,
@@ -619,7 +619,7 @@ git-p4.ignoredP4Labels::
 	unimportable labels are discovered.
 
 git-p4.importLabels::
-	Import p4 labels into git, as per --import-labels.
+	Import p4 labels into git, as per `--import-labels`.
 
 git-p4.labelImportRegexp::
 	Only p4 labels matching this regular expression will be imported. The
@@ -734,7 +734,7 @@ git-p4.attemptRCSCleanup::
 	present.
 
 git-p4.exportLabels::
-	Export Git tags to p4 labels, as per --export-labels.
+	Export Git tags to p4 labels, as per `--export-labels`.
 
 git-p4.labelExportRegexp::
 	Only p4 labels matching this regular expression will be exported. The
@@ -742,7 +742,7 @@ git-p4.labelExportRegexp::
 
 git-p4.conflict::
 	Specify submit behavior when a conflict with p4 is found, as per
-	--conflict.  The default behavior is 'ask'.
+	`--conflict`.  The default behavior is 'ask'.
 
 git-p4.disableRebase::
     Do not rebase the tree against p4/master following a submit.
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index 25d9fbe37a..a78721517b 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -101,13 +101,13 @@ Incompatible with `--revs`, or options that imply `--revs` (such as
 	the pack are stored using delta compression.  The
 	objects are first internally sorted by type, size and
 	optionally names and compared against the other objects
-	within --window to see if using delta compression saves
-	space.  --depth limits the maximum delta depth; making
+	within `--window` to see if using delta compression saves
+	space.  `--depth` limits the maximum delta depth; making
 	it too deep affects the performance on the unpacker
 	side, because delta data needs to be applied that many
 	times to get to the necessary object.
 +
-The default value for --window is 10 and --depth is 50. The maximum
+The default value for `--window` is 10 and `--depth` is 50. The maximum
 depth is 4095.
 
 --window-memory=<n>::
@@ -165,19 +165,19 @@ depth is 4095.
 	the standard error stream is not directed to a terminal.
 
 --all-progress::
-	When --stdout is specified then progress report is
+	When `--stdout` is specified then progress report is
 	displayed during the object count and compression phases
 	but inhibited during the write-out phase. The reason is
 	that in some cases the output stream is directly linked
 	to another command which may wish to display progress
 	status of its own as it processes incoming pack data.
-	This flag is like --progress except that it forces progress
-	report for the write-out phase as well even if --stdout is
+	This flag is like `--progress` except that it forces progress
+	report for the write-out phase as well even if `--stdout` is
 	used.
 
 --all-progress-implied::
-	This is used to imply --all-progress whenever progress display
-	is activated.  Unlike --all-progress this flag doesn't actually
+	This is used to imply `--all-progress` whenever progress display
+	is activated.  Unlike `--all-progress` this flag doesn't actually
 	force any progress display by itself.
 
 -q::
@@ -194,7 +194,7 @@ depth is 4095.
 --no-reuse-object::
 	This flag tells the command not to reuse existing object data at all,
 	including non deltified object, forcing recompression of everything.
-	This implies --no-reuse-delta. Useful only in the obscure case where
+	This implies `--no-reuse-delta`. Useful only in the obscure case where
 	wholesale enforcement of a different compression level on the
 	packed data is desired.
 
@@ -203,12 +203,12 @@ depth is 4095.
 	generated pack.  If not specified,  pack compression level is
 	determined first by pack.compression,  then by core.compression,
 	and defaults to -1,  the zlib default,  if neither is set.
-	Add --no-reuse-object if you want to force a uniform compression
+	Add `--no-reuse-object` if you want to force a uniform compression
 	level on all data no matter the source.
 
 --[no-]sparse::
 	Toggle the "sparse" algorithm to determine which objects to include in
-	the pack, when combined with the "--revs" option. This algorithm
+	the pack, when combined with the `--revs` option. This algorithm
 	only walks trees that appear in paths that introduce new objects.
 	This can have significant performance benefits when computing
 	a pack to send a small change. However, it is possible that extra
@@ -220,7 +220,7 @@ depth is 4095.
 --thin::
 	Create a "thin" pack by omitting the common objects between a
 	sender and a receiver in order to reduce network transfer. This
-	option only makes sense in conjunction with --stdout.
+	option only makes sense in conjunction with `--stdout`.
 +
 Note: A thin pack violates the packed archive format by omitting
 required objects and is thus unusable by Git without making it
@@ -229,7 +229,7 @@ self-contained. Use `git index-pack --fix-thin`
 
 --shallow::
 	Optimize a pack that will be provided to a client with a shallow
-	repository.  This option, combined with --thin, can result in a
+	repository.  This option, combined with `--thin`, can result in a
 	smaller pack at the cost of speed.
 
 --delta-base-offset::
@@ -279,16 +279,16 @@ So does `git bundle` (see linkgit:git-bundle[1]) when it creates a bundle.
 	A debug option to help with future "partial clone" development.
 	This option specifies how missing objects are handled.
 +
-The form '--missing=error' requests that pack-objects stop with an error if
+The form `--missing=error` requests that pack-objects stop with an error if
 a missing object is encountered.  If the repository is a partial clone, an
 attempt to fetch missing objects will be made before declaring them missing.
 This is the default action.
 +
-The form '--missing=allow-any' will allow object traversal to continue
+The form `--missing=allow-any` will allow object traversal to continue
 if a missing object is encountered.  No fetch of a missing object will occur.
 Missing objects will silently be omitted from the results.
 +
-The form '--missing=allow-promisor' is like 'allow-any', but will only
+The form `--missing=allow-promisor` is like 'allow-any', but will only
 allow object traversal to continue for EXPECTED promisor missing objects.
 No fetch of a missing object will occur.  An unexpected missing object will
 raise an error.
@@ -302,7 +302,7 @@ raise an error.
 
 --keep-unreachable::
 	Objects unreachable from the refs in packs named with
-	--unpacked= option are added to the resulting pack, in
+	`--unpacked`= option are added to the resulting pack, in
 	addition to the reachable objects that are not in packs marked
 	with *.keep files. This implies `--revs`.
 
@@ -363,7 +363,7 @@ to recompute deltas on the fly due to crossing island boundaries.
 
 When repacking with delta islands the delta window tends to get
 clogged with candidates that are forbidden by the config. Repacking
-with a big --window helps (and doesn't take as long as it otherwise
+with a big `--window` helps (and doesn't take as long as it otherwise
 might because we can reject some object pairs based on islands before
 doing any computation on the content).
 
diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt
index 442caff8a9..fb5b194b8a 100644
--- a/Documentation/git-patch-id.txt
+++ b/Documentation/git-patch-id.txt
@@ -34,15 +34,15 @@ OPTIONS
 	Use a "stable" sum of hashes as the patch ID. With this option:
 	 - Reordering file diffs that make up a patch does not affect the ID.
 	   In particular, two patches produced by comparing the same two trees
-	   with two different settings for "-O<orderfile>" result in the same
+	   with two different settings for `-O<orderfile>` result in the same
 	   patch ID signature, thereby allowing the computed result to be used
 	   as a key to index some meta-information about the change between
 	   the two trees;
 
 	 - Result is different from the value produced by git 1.9 and older
-	   or produced when an "unstable" hash (see --unstable below) is
+	   or produced when an "unstable" hash (see `--unstable` below) is
 	   configured - even when used on a diff output taken without any use
-	   of "-O<orderfile>", thereby making existing databases storing such
+	   of `-O<orderfile>`, thereby making existing databases storing such
 	   "unstable" or historical patch-ids unusable.
 
 	This is the default if patchid.stable is set to true.
diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt
index 03552dd86f..7bad035e47 100644
--- a/Documentation/git-prune.txt
+++ b/Documentation/git-prune.txt
@@ -75,7 +75,7 @@ should instead call 'git gc', which handles pruning along with
 many other housekeeping tasks.
 
 For a description of which objects are considered for pruning, see
-'git fsck''s --unreachable option.
+'git fsck''s `--unreachable` option.
 
 SEE ALSO
 --------
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 5c3fb67c01..edecf393d3 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -82,7 +82,7 @@ OPTIONS
 
 -v::
 --verbose::
-	Pass --verbose to git-fetch and git-merge.
+	Pass `--verbose` to git-fetch and git-merge.
 
 --[no-]recurse-submodules[=yes|on-demand|no]::
 	This option controls if new commits of populated submodules should
@@ -132,7 +132,7 @@ published that history already.  Do *not* use this option
 unless you have read linkgit:git-rebase[1] carefully.
 
 --no-rebase::
-	Override earlier --rebase.
+	Override earlier `--rebase`.
 
 Options related to fetching
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -239,7 +239,7 @@ include::transfer-data-leaks.txt[]
 
 BUGS
 ----
-Using --recurse-submodules can only fetch new commits in already checked
+Using `--recurse-submodules` can only fetch new commits in already checked
 out submodules right now. When e.g. upstream added a new submodule in the
 just fetched commits of the superproject the submodule itself cannot be
 fetched, making it impossible to check out that submodule later without
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index a953c7c387..fc91d41ce0 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -277,7 +277,7 @@ that specifies the expected current value of the ref explicitly are
 still experimental and their semantics may change as we gain experience
 with this feature.
 +
-"--no-force-with-lease" will cancel all the previous --force-with-lease on the
+`--no-force-with-lease` will cancel all the previous `--force-with-lease` on the
 command line.
 +
 A general note on safety: supplying this option without an expected
@@ -416,8 +416,8 @@ Specifying `--no-force-if-includes` disables this behavior.
 
 --[no-]verify::
 	Toggle the pre-push hook (see linkgit:githooks[5]).  The
-	default is --verify, giving the hook a chance to prevent the
-	push.  With --no-verify, the hook is bypassed completely.
+	default is `--verify`, giving the hook a chance to prevent the
+	push.  With `--no-verify`, the hook is bypassed completely.
 
 -4::
 --ipv4::
@@ -443,13 +443,13 @@ representing the status of a single ref. Each line is of the form:
  <flag> <summary> <from> -> <to> (<reason>)
 -------------------------------
 
-If --porcelain is used, then each line of the output is of the form:
+If `--porcelain` is used, then each line of the output is of the form:
 
 -------------------------------
  <flag> \t <from>:<to> \t <summary> (<reason>)
 -------------------------------
 
-The status of up-to-date refs is shown only if --porcelain or --verbose
+The status of up-to-date refs is shown only if `--porcelain` or `--verbose`
 option is used.
 
 flag::
diff --git a/Documentation/git-quiltimport.txt b/Documentation/git-quiltimport.txt
index 70562dc4c0..edae01d55d 100644
--- a/Documentation/git-quiltimport.txt
+++ b/Documentation/git-quiltimport.txt
@@ -21,7 +21,7 @@ in the quilt patchset.
 
 For each patch the code attempts to extract the author from the
 patch description.  If that fails it falls back to the author
-specified with --author.  If the --author flag was not given
+specified with `--author`.  If the `--author` flag was not given
 the patch description is displayed and the user is asked to
 interactively enter the author of the patch.
 
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 5fa8bab64c..3f53688170 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -38,7 +38,7 @@ OPTIONS
 	started.
 
 --reset::
-	Same as -m, except that unmerged entries are discarded instead
+	Same as `-m`, except that unmerged entries are discarded instead
 	of failing. When used with `-u`, updates leading to loss of
 	working tree changes will not abort the operation.
 
@@ -116,7 +116,7 @@ OPTIONS
 	located in.
 
 --[no-]recurse-submodules::
-	Using --recurse-submodules will update the content of all active
+	Using `--recurse-submodules` will update the content of all active
 	submodules according to the commit recorded in the superproject by
 	calling read-tree recursively, also setting the submodules' HEAD to be
 	detached at that commit.
@@ -227,7 +227,7 @@ refer to the presence of a path in the specified commit:
 In all "keep index" cases, the index entry stays as in the
 original index file.  If the entry is not up to date,
 'git read-tree' keeps the copy in the work tree intact when
-operating under the -u flag.
+operating under the `-u` flag.
 
 When this form of 'git read-tree' returns successfully, you can
 see which of the "local changes" that you made were carried forward by running
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index f08ae27e2a..f063d54623 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -34,7 +34,7 @@ description on `--fork-point` below); or by `git log HEAD`, if the
 `--root` option is specified.
 
 The current branch is reset to <upstream>, or <newbase> if the
---onto option was supplied.  This has the exact same effect as
+`--onto` option was supplied.  This has the exact same effect as
 `git reset --hard <upstream>` (or <newbase>).  ORIG_HEAD is set
 to point at the tip of the branch before the reset.
 
@@ -130,7 +130,7 @@ 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
+Another example of `--onto` option is to rebase part of a
 branch.  If we have the following situation:
 
 ------------
@@ -175,7 +175,7 @@ would result in the removal of commits F and G:
 ------------
 
 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>
+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
@@ -210,7 +210,7 @@ OPTIONS
 -------
 --onto <newbase>::
 	Starting point at which to create the new commits. If the
-	--onto option is not specified, the starting point is
+	`--onto` option is not specified, the starting point is
 	<upstream>.  May be any valid commit, and not just an
 	existing branch name.
 +
@@ -229,9 +229,9 @@ top of an upstream branch. While the feature is being worked on, the
 upstream branch may advance and it may not be the best idea to keep
 rebasing on top of the upstream but to keep the base commit as-is.
 +
-Although both this option and --fork-point find the merge base between
+Although both this option and `--fork-point` find the merge base between
 <upstream> and <branch>, this option uses the merge base as the _starting
-point_ on which new commits will be created, whereas --fork-point uses
+point_ on which new commits will be created, whereas `--fork-point` uses
 the merge base to determine the _set of commits_ which will be rebased.
 +
 See also INCOMPATIBLE OPTIONS below.
@@ -258,7 +258,7 @@ See also INCOMPATIBLE OPTIONS below.
 	Abort the rebase operation but HEAD is not reset back to the
 	original branch. The index and working tree are also left
 	unchanged as a result. If a temporary stash entry was created
-	using --autostash, it will be saved to the stash list.
+	using `--autostash`, it will be saved to the stash list.
 
 --apply::
 	Use applying strategies to rebase (calling `git-am`
@@ -276,13 +276,13 @@ See also INCOMPATIBLE OPTIONS below.
 	With ask (implied by --interactive), the rebase will halt when
 	an empty commit is applied allowing you to choose whether to
 	drop it, edit files more, or just commit the empty changes.
-	Other options, like --exec, will use the default of drop unless
-	-i/--interactive is explicitly specified.
+	Other options, like `--exec`, will use the default of drop unless
+	`-i`/`--interactive` is explicitly specified.
 +
-Note that commits which start empty are kept (unless --no-keep-empty
+Note that commits which start empty are kept (unless `--no-keep-empty`
 is specified), and commits which are clean cherry-picks (as determined
 by `git log --cherry-mark ...`) are detected and dropped as a
-preliminary step (unless --reapply-cherry-picks is passed).
+preliminary step (unless `--reapply-cherry-picks` is passed).
 +
 See also INCOMPATIBLE OPTIONS below.
 
@@ -291,7 +291,7 @@ See also INCOMPATIBLE OPTIONS below.
 	Do not keep commits that start empty before the rebase
 	(i.e. that do not change anything from its parent) in the
 	result.  The default is to keep commits which start empty,
-	since creating such commits requires passing the --allow-empty
+	since creating such commits requires passing the `--allow-empty`
 	override flag to `git commit`, signifying that a user is very
 	intentionally creating such a commit and thus wants to keep
 	it.
@@ -303,7 +303,7 @@ flag exists as a convenient shortcut, such as for cases where external
 tools generate many empty commits and you want them all removed.
 +
 For commits which do not start empty but become empty after rebasing,
-see the --empty flag.
+see the `--empty` flag.
 +
 See also INCOMPATIBLE OPTIONS below.
 
@@ -362,7 +362,7 @@ See also INCOMPATIBLE OPTIONS below.
 --strategy=<strategy>::
 	Use the given merge strategy.
 	If there is no `-s` option 'git merge-recursive' is used
-	instead.  This implies --merge.
+	instead.  This implies `--merge`.
 +
 Because 'git rebase' replays each commit from the working branch
 on top of the <upstream> branch using the given strategy, using
@@ -396,11 +396,11 @@ See also INCOMPATIBLE OPTIONS below.
 
 -q::
 --quiet::
-	Be quiet. Implies --no-stat.
+	Be quiet. Implies `--no-stat`.
 
 -v::
 --verbose::
-	Be verbose. Implies --stat.
+	Be verbose. Implies `--stat`.
 
 --stat::
 	Show a diffstat of what changed upstream since the last rebase. The
@@ -415,13 +415,13 @@ See also INCOMPATIBLE OPTIONS below.
 
 --verify::
 	Allows the pre-rebase hook to run, which is the default.  This option can
-	be used to override --no-verify.  See also linkgit:githooks[5].
+	be used to override `--no-verify`.  See also linkgit:githooks[5].
 
 -C<n>::
 	Ensure at least <n> lines of surrounding context match before
 	and after each change.  When fewer lines of surrounding
 	context exist they all must match.  By default no context is
-	ever ignored.  Implies --apply.
+	ever ignored.  Implies `--apply`.
 +
 See also INCOMPATIBLE OPTIONS below.
 
@@ -444,7 +444,7 @@ details).
 	and <branch> when calculating which commits have been
 	introduced by <branch>.
 +
-When --fork-point is active, 'fork_point' will be used instead of
+When `--fork-point` is active, 'fork_point' will be used instead of
 <upstream> to calculate the set of commits to rebase, where
 'fork_point' is the result of `git merge-base --fork-point <upstream>
 <branch>` command (see linkgit:git-merge-base[1]).  If 'fork_point'
@@ -478,7 +478,7 @@ if the other side had no changes that conflicted.
 --whitespace=<option>::
 	This flag is passed to the 'git apply' program
 	(see linkgit:git-apply[1]) that applies the patch.
-	Implies --apply.
+	Implies `--apply`.
 +
 See also INCOMPATIBLE OPTIONS below.
 
@@ -582,10 +582,10 @@ See also INCOMPATIBLE OPTIONS below.
 --root::
 	Rebase all commits reachable from <branch>, instead of
 	limiting them with an <upstream>.  This allows you to rebase
-	the root commit(s) on a branch.  When used with --onto, it
+	the root commit(s) on a branch.  When used with `--onto`, it
 	will skip changes already contained in <newbase> (instead of
-	<upstream>) whereas without --onto it will operate on every change.
-	When used together with both --onto and --preserve-merges,
+	<upstream>) whereas without `--onto` it will operate on every change.
+	When used together with both `--onto` and `--preserve-merges`,
 	'all' root commits will be rewritten to have <newbase> as parent
 	instead.
 +
@@ -629,39 +629,39 @@ INCOMPATIBLE OPTIONS
 
 The following options:
 
- * --apply
- * --whitespace
- * -C
+ * `--apply`
+ * `--whitespace`
+ * `-C`
 
 are incompatible with the following options:
 
- * --merge
- * --strategy
- * --strategy-option
- * --allow-empty-message
- * --[no-]autosquash
- * --rebase-merges
- * --preserve-merges
- * --interactive
- * --exec
- * --no-keep-empty
- * --empty=
- * --reapply-cherry-picks
- * --edit-todo
- * --root when used in combination with --onto
+ * `--merge`
+ * `--strategy`
+ * `--strategy-option`
+ * `--allow-empty-message`
+ * `--[no-]autosquash`
+ * `--rebase-merges`
+ * `--preserve-merges`
+ * `--interactive`
+ * `--exec`
+ * `--no-keep-empty`
+ * `--empty=`
+ * `--reapply-cherry-picks`
+ * `--edit-todo`
+ * `--root` when used in combination with `--onto`
 
 In addition, the following pairs of options are incompatible:
 
- * --preserve-merges and --interactive
- * --preserve-merges and --signoff
- * --preserve-merges and --rebase-merges
- * --preserve-merges and --empty=
- * --preserve-merges and --ignore-whitespace
- * --preserve-merges and --committer-date-is-author-date
- * --preserve-merges and --ignore-date
- * --keep-base and --onto
- * --keep-base and --root
- * --fork-point and --root
+ * `--preserve-merges` and `--interactive` 
+ * `--preserve-merges` and `--signoff` 
+ * `--preserve-merges` and `--rebase-merges` 
+ * `--preserve-merges` and `--empty=` 
+ * `--preserve-merges` and `--ignore-whitespace` 
+ * `--preserve-merges` and `--committer-date-is-author-date` 
+ * `--preserve-merges` and `--ignore-date` 
+ * `--keep-base` and `--onto` 
+ * `--keep-base` and `--root` 
+ * `--fork-point` and `--root` 
 
 BEHAVIORAL DIFFERENCES
 -----------------------
@@ -683,13 +683,13 @@ also drops commits that become empty and has no option for controlling
 this behavior.
 
 The merge backend keeps intentionally empty commits by default (though
-with -i they are marked as empty in the todo list editor, or they can
-be dropped automatically with --no-keep-empty).
+with `-i` they are marked as empty in the todo list editor, or they can
+be dropped automatically with `--no-keep-empty`).
 
 Similar to the apply backend, by default the merge backend drops
-commits that become empty unless -i/--interactive is specified (in
+commits that become empty unless `-i`/`--interactive` is specified (in
 which case it stops and asks the user what to do).  The merge backend
-also has an --empty={drop,keep,ask} option for changing the behavior
+also has an `--empty={drop,keep,ask}` option for changing the behavior
 of handling commits that become empty.
 
 Directory rename detection
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 317d63cf0d..98373e4f36 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -96,7 +96,7 @@ to the new separate pack will be written.
 	affects the performance on the unpacker side, because delta data needs
 	to be applied that many times to get to the necessary object.
 +
-The default value for --window is 10 and --depth is 50. The maximum
+The default value for `--window` is 10 and `--depth` is 50. The maximum
 depth is 4095.
 
 --threads=<n>::
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 252e2d4e47..e9e816a986 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -89,7 +89,7 @@ but carries forward unmerged index entries.
 	changes, reset is aborted.
 
 --[no-]recurse-submodules::
-	When the working tree is updated, using --recurse-submodules will
+	When the working tree is updated, using `--recurse-submodules` will
 	also recursively reset the working tree of all active submodules
 	according to the commit recorded in the superproject, also setting
 	the submodules' HEAD to be detached at that commit.
@@ -345,7 +345,7 @@ $ git commit ...                            <8>
 ------------
 +
 <1> First, reset the history back one commit so that we remove the original
-    commit, but leave the working tree with all the changes. The -N ensures
+    commit, but leave the working tree with all the changes. The `-N` ensures
     that any new files added with `HEAD` are still marked so that `git add -p`
     will find them.
 <2> Next, we interactively select diff hunks to add using the `git add -p`
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 6b8ca085aa..4b1af8c5a6 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -152,7 +152,7 @@ for another option.
 	form as close to the original input as possible.
 
 --symbolic-full-name::
-	This is similar to --symbolic, but it omits input that
+	This is similar to `--symbolic`, but it omits input that
 	are not refs (i.e. branch or tag names; or more
 	explicitly disambiguating "heads/master" form, when you
 	want to name the "master" branch when there is an
@@ -306,12 +306,12 @@ Other Options
 --since=datestring::
 --after=datestring::
 	Parse the date string, and output the corresponding
-	--max-age= parameter for 'git rev-list'.
+	`--max-age=` parameter for 'git rev-list'.
 
 --until=datestring::
 --before=datestring::
 	Parse the date string, and output the corresponding
-	--min-age= parameter for 'git rev-list'.
+	`--min-age=` parameter for 'git rev-list'.
 
 <args>...::
 	Flags and parameters to be parsed.
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index ab750367fd..e7ff1b5fbd 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -151,7 +151,7 @@ still uses a .git directory, `git rm` will move the submodules
 git directory into the superprojects git directory to protect
 the submodule's history. If it exists the submodule.<name> section
 in the linkgit:gitmodules[5] file will also be removed and that file
-will be staged (unless --cached or -n are used).
+will be staged (unless `--cached` or `-n` are used).
 
 A submodule is considered up to date when the HEAD is the same as
 recorded in the index, no tracked files are modified and no untracked
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 93708aefea..afd41a010e 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -87,7 +87,7 @@ See the CONFIGURATION section for `sendemail.multiEdit`.
 --reply-to=<address>::
 	Specify the address where replies from recipients should go to.
 	Use this if replies to messages should go to another address than what
-	is specified with the --from parameter.
+	is specified with the `--from` parameter.
 
 --in-reply-to=<identifier>::
 	Make the first mail (or all the mails with `--no-thread`) appear as a
@@ -108,19 +108,19 @@ illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
       [PATCH v2 2/3] New tests
       [PATCH v2 3/3] Implementation
 +
-Only necessary if --compose is also set.  If --compose
+Only necessary if `--compose` is also set.  If `--compose`
 is not set, this will be prompted for.
 
 --subject=<string>::
 	Specify the initial subject of the email thread.
-	Only necessary if --compose is also set.  If --compose
+	Only necessary if `--compose` is also set.  If `--compose`
 	is not set, this will be prompted for.
 
 --to=<address>,...::
 	Specify the primary recipient of the emails generated. Generally, this
 	will be the upstream maintainer of the project involved. Default is the
 	value of the `sendemail.to` configuration value; if that is unspecified,
-	and --to-cmd is not specified, this will be prompted for.
+	and `--to-cmd` is not specified, this will be prompted for.
 +
 This option may be specified multiple times.
 
@@ -163,7 +163,7 @@ Sending
 	This is useful if your default address is not the address that is
 	subscribed to a list. In order to use the 'From' address, set the
 	value to "auto". If you use the sendmail binary, you must have
-	suitable privileges for the -f parameter.  Default is the value of the
+	suitable privileges for the `-f` parameter.  Default is the value of the
 	`sendemail.envelopeSender` configuration variable; if that is
 	unspecified, choosing the envelope sender is left to your MTA.
 
@@ -232,12 +232,12 @@ a password is obtained using 'git-credential'.
 	Default value can be specified by the `sendemail.smtpServerOption`
 	configuration option.
 +
-The --smtp-server-option option must be repeated for each option you want
+The `--smtp-server-option` option must be repeated for each option you want
 to pass to the server. Likewise, different lines in the configuration files
 must be used for each option.
 
 --smtp-ssl::
-	Legacy alias for '--smtp-encryption ssl'.
+	Legacy alias for `--smtp-encryption ssl`.
 
 --smtp-ssl-cert-path::
 	Path to a store of trusted CA certificates for SMTP SSL/TLS
@@ -264,7 +264,7 @@ must be used for each option.
 	Some email servers (e.g. smtp.163.com) limit the number emails to be
 	sent per session (connection) and this will lead to a failure when
 	sending many messages.  With this option, send-email will disconnect after
-	sending $<num> messages and wait for a few seconds (see --relogin-delay)
+	sending $<num> messages and wait for a few seconds (see `--relogin-delay`)
 	and reconnect, to work around such a limit.  You may want to
 	use some form of credential helper to avoid having to retype
 	your password every time this happens.  Defaults to the
@@ -272,7 +272,7 @@ must be used for each option.
 
 --relogin-delay=<int>::
 	Waiting $<int> seconds before reconnecting to SMTP server. Used together
-	with --batch-size option.  Defaults to the `sendemail.smtpReloginDelay`
+	with `--batch-size` option.  Defaults to the `sendemail.smtpReloginDelay`
 	configuration variable.
 
 Automating
@@ -300,7 +300,7 @@ Automating
 
 --[no-]chain-reply-to::
 	If this is set, each email will be sent as a reply to the previous
-	email sent.  If disabled with "--no-chain-reply-to", all emails after
+	email sent.  If disabled with `--no-chain-reply-to`, all emails after
 	the first will be sent as replies to the first email sent.  When using
 	this, it is recommended that the first file given be an overview of the
 	entire patch series. Disabled by default, but the `sendemail.chainReplyTo`
@@ -315,19 +315,19 @@ Automating
 --[no-]signed-off-by-cc::
 	If this is set, add emails found in the `Signed-off-by` trailer or Cc: lines to the
 	cc list. Default is the value of `sendemail.signedoffbycc` configuration
-	value; if that is unspecified, default to --signed-off-by-cc.
+	value; if that is unspecified, default to `--signed-off-by-cc`.
 
 --[no-]cc-cover::
 	If this is set, emails found in Cc: headers in the first patch of
 	the series (typically the cover letter) are added to the cc list
 	for each email set. Default is the value of 'sendemail.cccover'
-	configuration value; if that is unspecified, default to --no-cc-cover.
+	configuration value; if that is unspecified, default to `--no-cc-cover`.
 
 --[no-]to-cover::
 	If this is set, emails found in To: headers in the first patch of
 	the series (typically the cover letter) are added to the to list
 	for each email set. Default is the value of 'sendemail.tocover'
-	configuration value; if that is unspecified, default to --no-to-cover.
+	configuration value; if that is unspecified, default to `--no-to-cover`.
 
 --suppress-cc=<category>::
 	Specify an additional category of recipients to suppress the
@@ -345,19 +345,19 @@ Automating
 - 'misc-by' will avoid including anyone mentioned in Acked-by,
   Reviewed-by, Tested-by and other "-by" lines in the patch body,
   except Signed-off-by (use 'sob' for that).
-- 'cccmd' will avoid running the --cc-cmd.
+- 'cccmd' will avoid running the `--cc-cmd`.
 - 'body' is equivalent to 'sob' + 'bodycc' + 'misc-by'.
 - 'all' will suppress all auto cc values.
 --
 +
 Default is the value of `sendemail.suppresscc` configuration value; if
-that is unspecified, default to 'self' if --suppress-from is
-specified, as well as 'body' if --no-signed-off-cc is specified.
+that is unspecified, default to 'self' if `--suppress-from` is
+specified, as well as 'body' if `--no-signed-off-cc` is specified.
 
 --[no-]suppress-from::
 	If this is set, do not add the From: address to the cc: list.
 	Default is the value of `sendemail.suppressFrom` configuration
-	value; if that is unspecified, default to --no-suppress-from.
+	value; if that is unspecified, default to `--no-suppress-from`.
 
 --[no-]thread::
 	If this is set, the In-Reply-To and References headers will be
@@ -366,10 +366,10 @@ specified, as well as 'body' if --no-signed-off-cc is specified.
 	wording) or to the first email (`shallow` threading) is
 	governed by "--[no-]chain-reply-to".
 +
-If disabled with "--no-thread", those headers will not be added
-(unless specified with --in-reply-to).  Default is the value of the
+If disabled with `--no-thread`, those headers will not be added
+(unless specified with `--in-reply-to`).  Default is the value of the
 `sendemail.thread` configuration value; if that is unspecified,
-default to --thread.
+default to `--thread`.
 +
 It is up to the user to ensure that no In-Reply-To header already
 exists when 'git send-email' is asked to add it (especially note that
@@ -389,7 +389,7 @@ Administering
 - 'never' will never confirm before sending
 - 'cc' will confirm before sending when send-email has automatically
   added addresses from the patch to the Cc list
-- 'compose' will confirm before sending the first message when using --compose.
+- 'compose' will confirm before sending the first message when using `--compose`.
 - 'auto' is equivalent to 'cc' + 'compose'
 --
 +
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 44fd146b91..2cd2d823b3 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -32,7 +32,7 @@ OPTIONS
 	a directory on the default $PATH.
 
 --exec=<git-receive-pack>::
-	Same as --receive-pack=<git-receive-pack>.
+	Same as `--receive-pack`=<git-receive-pack>.
 
 --all::
 	Instead of explicitly specifying which refs to update,
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index 5cc2fcefba..0ce603646f 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -126,7 +126,7 @@ OPTIONS
 	default to color output.
 	Same as `--color=never`.
 
-Note that --more, --list, --independent and --merge-base options
+Note that `--more`, `--list`, `--independent` and `--merge-base` options
 are mutually exclusive.
 
 
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index ab4d271925..8c739adc70 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -23,7 +23,7 @@ particular ref exists.
 
 By default, shows the tags, heads, and remote refs.
 
-The --exclude-existing form is a filter that does the inverse. It reads
+The `--exclude-existing` form is a filter that does the inverse. It reads
 refs from stdin, one ref per line, and shows those that don't exist in
 the local repository.
 
@@ -54,7 +54,7 @@ OPTIONS
 --hash[=<n>]::
 
 	Only show the SHA-1 hash, not the reference name. When combined with
-	--dereference the dereferenced tag will still be shown after the SHA-1.
+	`--dereference` the dereferenced tag will still be shown after the SHA-1.
 
 --verify::
 
@@ -110,7 +110,7 @@ $ git show-ref --head --dereference
 ...
 -----------------------------------------------------------------------------
 
-When using --hash (and not --dereference) the output format is: '<SHA-1 ID>'
+When using `--hash` (and not `--dereference`) the output format is: '<SHA-1 ID>'
 
 -----------------------------------------------------------------------------
 $ git show-ref --heads --hash
@@ -145,7 +145,7 @@ will only match the exact branch called "master".
 If nothing matches, 'git show-ref' will return an error code of 1,
 and in the case of verification, it will show an error message.
 
-For scripting, you can ask it to be quiet with the "--quiet" flag, which
+For scripting, you can ask it to be quiet with the `--quiet` flag, which
 allows you to do things like
 
 -----------------------------------------------------------------------------
@@ -157,11 +157,11 @@ to check whether a particular branch exists or not (notice how we don't
 actually want to show any results, and we want to use the full refname for it
 in order to not trigger the problem with ambiguous partial matches).
 
-To show only tags, or only proper branch heads, use "--tags" and/or "--heads"
+To show only tags, or only proper branch heads, use `--tags` and/or `--heads`
 respectively (using both means that it shows tags and heads, but not other
 random references under the refs/ subdirectory).
 
-To do automatic tag object dereferencing, use the "-d" or "--dereference"
+To do automatic tag object dereferencing, use the `-d` or `--dereference`
 flag, so you can do
 
 -----------------------------------------------------------------------------
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 83f38e3198..2fa3bc58f7 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -109,7 +109,7 @@ It is optional: it defaults to 'traditional'.
 The possible options are:
 
 	- 'traditional' - Shows ignored files and directories, unless
-			  --untracked-files=all is specified, in which case
+			  `--untracked-files=all` is specified, in which case
 			  individual files in ignored directories are
 			  displayed.
 	- 'no'	        - Show no ignored files.
@@ -252,7 +252,7 @@ via `git add` in the superproject to prepare a commit.
 'm' and '?' are applied recursively. For example if a nested submodule
 in a submodule contains an untracked file, this is reported as '?' as well.
 
-If -b is used the short-format status is preceded by a line
+If `-b` is used the short-format status is preceded by a line
 
     ## branchname tracking info
 
@@ -271,7 +271,7 @@ format, with a few exceptions:
 2. The user's status.relativePaths configuration is not respected; paths
    shown will always be relative to the repository root.
 
-There is also an alternate -z format recommended for machine parsing. In
+There is also an alternate `-z` format recommended for machine parsing. In
 that format, the status field is the same, but some other things
 change.  First, the '\->' is omitted from rename entries and the field
 order is reversed (e.g 'from \-> to' becomes 'to from'). Second, a NUL
@@ -425,11 +425,11 @@ directory.
 If `status.submoduleSummary` is set to a non zero number or true (identical
 to -1 or an unlimited number), the submodule summary will be enabled for
 the long format and a summary of commits for modified submodules will be
-shown (see --summary-limit option of linkgit:git-submodule[1]). Please note
+shown (see `--summary-limit` option of linkgit:git-submodule[1]). Please note
 that the summary output from the status command will be suppressed for all
 submodules when `diff.ignoreSubmodules` is set to 'all' or only for those
 submodules where `submodule.<name>.ignore=all`. To also view the summary for
-ignored submodules you can either use the --ignore-submodules=dirty command
+ignored submodules you can either use the `--ignore-submodules=dirty` command
 line option or the 'git submodule summary' command, which shows a similar
 output but does not honor these settings.
 
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 7e5f995f77..1bcde161ca 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -432,7 +432,7 @@ options carefully.
 
 --[no-]single-branch::
 	This option is only valid for the update command.
-	Clone only one branch during update: HEAD or one specified by --branch.
+	Clone only one branch during update: HEAD or one specified by `--branch`.
 
 <path>...::
 	Paths to submodule(s). When specified this will restrict the command
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 67b143cc81..3f55e9c419 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -17,8 +17,8 @@ It provides a bidirectional flow of changes between a Subversion and a Git
 repository.
 
 'git svn' can track a standard Subversion repository,
-following the common "trunk/branches/tags" layout, with the --stdlayout option.
-It can also follow branches and tags in any layout with the -T/-t/-b options
+following the common "trunk/branches/tags" layout, with the `--stdlayout` option.
+It can also follow branches and tags in any layout with the `-T`/`-t`/`-b` options
 (see options to 'init' below, and also the 'clone' command).
 
 Once tracking a Subversion repository (with any of the above methods), the Git
@@ -32,7 +32,7 @@ COMMANDS
 	Initializes an empty Git repository with additional
 	metadata directories for 'git svn'.  The Subversion URL
 	may be specified as a command-line argument, or as full
-	URL arguments to -T/-t/-b.  Optionally, the target
+	URL arguments to `-T`/`-t`/`-b`.  Optionally, the target
 	directory to operate on can be specified as a second
 	argument.  Normally this command initializes the current
 	directory.
@@ -47,11 +47,11 @@ COMMANDS
 --stdlayout;;
 	These are optional command-line options for init.  Each of
 	these flags can point to a relative repository path
-	(--tags=project/tags) or a full url
-	(--tags=https://foo.org/project/tags).
-	You can specify more than one --tags and/or --branches options, in case
+	(`--tags=project/tags`) or a full url
+	(`--tags=https://foo.org/project/tags`).
+	You can specify more than one `--tags` and/or `--branches` options, in case
 	your Subversion repository places tags or branches under multiple paths.
-	The option --stdlayout is
+	The option `--stdlayout` is
 	a shorthand way of setting trunk,tags,branches as the relative paths,
 	which is the Subversion default. If any of the other options are given
 	as well, they take precedence.
@@ -77,7 +77,7 @@ COMMANDS
 	to the names of remotes if trunk/branches/tags are
 	specified.  The prefix does not automatically include a
 	trailing slash, so be sure you include one in the
-	argument if that is what you want.  If --branches/-b is
+	argument if that is what you want.  If `--branches`/`-b` is
 	specified, the prefix must include a trailing slash.
 	Setting a prefix (with a trailing slash) is strongly
 	encouraged in any case, as your SVN-tracking refs will
@@ -108,8 +108,8 @@ your Perl's Getopt::Long is < v2.37).
 	be preserved as a config key.  See 'fetch' for a description
 	of `--include-paths`.
 --no-minimize-url;;
-	When tracking multiple directories (using --stdlayout,
-	--branches, or --tags options), git svn will attempt to connect
+	When tracking multiple directories (using `--stdlayout`,
+	`--branches`, or `--tags` options), git svn will attempt to connect
 	to the root (or highest allowed level) of the Subversion
 	repository.  This default allows better tracking of history if
 	entire projects are moved within a repository, but may cause
@@ -130,7 +130,7 @@ This automatically updates the rev_map if needed (see
 
 --localtime;;
 	Store Git commit times in the local time zone instead of UTC.  This
-	makes 'git log' (even without --date=local) show the same times
+	makes 'git log' (even without `--date=local`) show the same times
 	that `svn log` would in the local time zone.
 +
 This doesn't interfere with interoperating with the Subversion
@@ -220,7 +220,7 @@ config key: svn-remote.<name>.include-paths
 	are also tracked and removed when no longer necessary.
 
 --placeholder-filename=<filename>;;
-	Set the name of placeholder files created by --preserve-empty-dirs.
+	Set the name of placeholder files created by `--preserve-empty-dirs`.
 	Default: ".gitignore"
 
 'rebase'::
@@ -317,7 +317,7 @@ committing anything to SVN.
 -d<path>;;
 --destination=<path>;;
 
-	If more than one --branches (or --tags) option was given to the 'init'
+	If more than one `--branches` (or `--tags`) option was given to the 'init'
 	or 'clone' command, you must provide the location of the branch (or
 	tag) you wish to create in the SVN repository.  <path> specifies which
 	path to use to create the branch or tag and should match the pattern
@@ -327,7 +327,7 @@ committing anything to SVN.
 	git config --get-all svn-remote.<name>.branches
 	git config --get-all svn-remote.<name>.tags
 +
-where <name> is the name of the SVN repository as specified by the -R option to
+where <name> is the name of the SVN repository as specified by the `-R` option to
 'init' (or "svn" by default).
 
 --username;;
@@ -345,7 +345,7 @@ where <name> is the name of the SVN repository as specified by the -R option to
 
 --parents;;
 	Create parent folders. This parameter is equivalent to the parameter
-	--parents on svn cp commands and is useful for non-standard repository
+	`--parents` on svn cp commands and is useful for non-standard repository
 	layouts.
 
 'tag'::
@@ -354,7 +354,7 @@ where <name> is the name of the SVN repository as specified by the -R option to
 
 'log'::
 	This should make it easy to look up svn log messages when svn
-	users refer to -r/--revision numbers.
+	users refer to `-r`/`--revision` numbers.
 +
 The following features from `svn log' are supported:
 +
@@ -365,10 +365,10 @@ The following features from `svn log' are supported:
 	HEAD, NEXT, BASE, PREV, etc ...
 -v;;
 --verbose;;
-	it's not completely compatible with the --verbose
+	it's not completely compatible with the `--verbose`
 	output in svn log, but reasonably close.
 --limit=<n>;;
-	is NOT the same as --max-count, doesn't count
+	is NOT the same as `--max-count`, doesn't count
 	merged/excluded commits
 --incremental;;
 	supported
@@ -380,7 +380,7 @@ New features:
 --show-commit;;
 	shows the Git commit sha1, as well
 --oneline;;
-	our version of --pretty=oneline
+	our version of `--pretty=oneline`
 --
 +
 NOTE: SVN itself only stores times in UTC and nothing else. The regular svn
@@ -433,7 +433,7 @@ Any other arguments are passed directly to 'git log'
 'create-ignore'::
 	Recursively finds the svn:ignore property on directories and
 	creates matching .gitignore files. The resulting files are staged to
-	be committed, but are not committed. Use -r/--revision to refer to a
+	be committed, but are not committed. Use `-r`/`--revision` to refer to a
 	specific revision.
 
 'show-ignore'::
@@ -458,7 +458,7 @@ Any other arguments are passed directly to 'git log'
 	URL of the target Subversion repository.  The final argument
 	(URL) may be omitted if you are working from a 'git svn'-aware
 	repository (that has been `init`-ed with 'git svn').
-	The -r<revision> option is required for this.
+	The `-r<revision>` option is required for this.
 +
 The commit message is supplied either directly with the `-m` or `-F`
 option, or indirectly from the tag or commit when the second tree-ish
@@ -477,18 +477,18 @@ denotes such an object, or it is requested by invoking an editor (see
 
 'info'::
 	Shows information about a file or directory similar to what
-	`svn info' provides.  Does not currently support a -r/--revision
-	argument.  Use the --url option to output only the value of the
+	`svn info' provides.  Does not currently support a `-r`/`--revision`
+	argument.  Use the `--url` option to output only the value of the
 	'URL:' field.
 
 'proplist'::
 	Lists the properties stored in the Subversion repository about a
-	given file or directory.  Use -r/--revision to refer to a specific
+	given file or directory.  Use `-r`/`--revision` to refer to a specific
 	Subversion revision.
 
 'propget'::
 	Gets the Subversion property given as the first argument, for a
-	file.  A specific revision can be specified with -r/--revision.
+	file.  A specific revision can be specified with `-r`/`--revision`.
 
 'propset'::
 	Sets the Subversion property given as the first argument, to the
@@ -505,7 +505,7 @@ This will set the property 'svn:keywords' to 'FreeBSD=%H' for the file
 'devel/py-tipper/Makefile'.
 
 'show-externals'::
-	Shows the Subversion externals.  Use -r/--revision to specify a
+	Shows the Subversion externals.  Use `-r`/`--revision` to specify a
 	specific revision.
 
 'gc'::
@@ -517,10 +517,10 @@ This will set the property 'svn:keywords' to 'FreeBSD=%H' for the file
 	This allows you to re-'fetch' an SVN revision.  Normally the
 	contents of an SVN revision should never change and 'reset'
 	should not be necessary.  However, if SVN permissions change,
-	or if you alter your --ignore-paths option, a 'fetch' may fail
+	or if you alter your `--ignore-paths` option, a 'fetch' may fail
 	with "not found in commit" (file not previously visible) or
 	"checksum mismatch" (missed a modification).  If the problem
-	file cannot be ignored forever (with --ignore-paths) the only
+	file cannot be ignored forever (with `--ignore-paths`) the only
 	way to repair the repo is to use 'reset'.
 +
 Only the rev_map and refs/remotes/git-svn are changed (see
@@ -735,8 +735,8 @@ ADVANCED OPTIONS
 
 --follow-parent::
 	This option is only relevant if we are tracking branches (using
-	one of the repository layout options --trunk, --tags,
-	--branches, --stdlayout). For each tracked branch, try to find
+	one of the repository layout options `--trunk`, `--tags`,
+	`--branches`, `--stdlayout`). For each tracked branch, try to find
 	out where its revision was copied from, and set
 	a suitable parent in the first Git commit for the branch.
 	This is especially helpful when we're tracking a directory
@@ -747,7 +747,7 @@ ADVANCED OPTIONS
 	However, following long/convoluted histories can take a long
 	time, so disabling this feature may speed up the cloning
 	process. This feature is enabled by default, use
-	--no-follow-parent to disable it.
+	`--no-follow-parent` to disable it.
 +
 [verse]
 config key: svn.followparent
@@ -951,7 +951,7 @@ compatibility with SVN (see the CAVEATS section below).
 
 HANDLING OF SVN BRANCHES
 ------------------------
-If 'git svn' is configured to fetch branches (and --follow-branches
+If 'git svn' is configured to fetch branches (and `--follow-branches`
 is in effect), it sometimes creates multiple Git branches for one
 SVN branch, where the additional branches have names of the form
 'branchname@nnn' (with nnn an SVN revision number).  These additional
@@ -1031,14 +1031,14 @@ before 'dcommit' on will require forcing an overwrite of the existing ref
 on the remote repository.  This is generally considered bad practice,
 see the linkgit:git-push[1] documentation for details.
 
-Do not use the --amend option of linkgit:git-commit[1] on a change you've
-already dcommitted.  It is considered bad practice to --amend commits
+Do not use the `--amend` option of linkgit:git-commit[1] on a change you've
+already dcommitted.  It is considered bad practice to `--amend` commits
 you've already pushed to a remote repository for other users, and
 dcommit with SVN is analogous to that.
 
 When cloning an SVN repository, if none of the options for describing
-the repository layout is used (--trunk, --tags, --branches,
---stdlayout), 'git svn clone' will create a Git repository with
+the repository layout is used (`--trunk`, `--tags`, `--branches`,
+`--stdlayout`), 'git svn clone' will create a Git repository with
 completely linear history, where branches and tags appear as separate
 directories in the working copy.  While this is the easiest way to get a
 copy of a complete repository, for projects with many branches it will
@@ -1051,7 +1051,7 @@ without giving any repository layout options.  If the full history with
 branches and tags is required, the options `--trunk` / `--branches` /
 `--tags` must be used.
 
-When using multiple --branches or --tags, 'git svn' does not automatically
+When using multiple `--branches` or `--tags`, 'git svn' does not automatically
 handle name collisions (for example, if two branches from different paths have
 the same name, or if a branch and a tag have the same name).  In these cases,
 use 'init' to set up your Git repository then, before your first 'fetch', edit
@@ -1142,7 +1142,7 @@ Multiple fetch, branches, and tags keys are supported:
 ------------------------------------------------------------------------
 
 Creating a branch in such a configuration requires disambiguating which
-location to use using the -d or --destination flag:
+location to use using the `-d` or `--destination` flag:
 
 ------------------------------------------------------------------------
 $ git svn branch -d branches/server release-2-3-0
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 31a97a1b6c..b802972bb2 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -111,7 +111,7 @@ options for details.
 
 --sort=<key>::
 	Sort based on the key given.  Prefix `-` to sort in
-	descending order of the value. You may use the --sort=<key> option
+	descending order of the value. You may use the `--sort=<key>` option
 	multiple times, in which case the last key becomes the primary
 	key. Also supports "version:refname" or "v:refname" (tag
 	names are treated as versions). The "version:refname" sort
@@ -236,7 +236,7 @@ On Re-tagging
 What should you do when you tag a wrong commit and you would
 want to re-tag?
 
-If you never pushed anything out, just re-tag it. Use "-f" to
+If you never pushed anything out, just re-tag it. Use `-f` to
 replace the old one. And you're done.
 
 But if you have pushed things out (or others could just read
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 2853f168d9..936b64045e 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -56,21 +56,21 @@ OPTIONS
 	updates are needed by checking stat() information.
 
 -q::
-        Quiet.  If --refresh finds that the index needs an update, the
+        Quiet.  If `--refresh` finds that the index needs an update, the
         default behavior is to error out.  This option makes
 	'git update-index' continue anyway.
 
 --ignore-submodules::
 	Do not try to update submodules.  This option is only respected
-	when passed before --refresh.
+	when passed before `--refresh`.
 
 --unmerged::
-        If --refresh finds unmerged changes in the index, the default
+        If `--refresh` finds unmerged changes in the index, the default
 	behavior is to error out.  This option makes 'git update-index'
         continue anyway.
 
 --ignore-missing::
-	Ignores missing files during a --refresh
+	Ignores missing files during a `--refresh`
 
 --cacheinfo <mode>,<object>,<path>::
 --cacheinfo <mode> <object> <path>::
@@ -140,13 +140,13 @@ you will need to handle the situation manually.
 
 --force-remove::
 	Remove the file from the index even when the working directory
-	still has such a file. (Implies --remove.)
+	still has such a file. (Implies `--remove`.)
 
 --replace::
 	By default, when a file `path` exists in the index,
 	'git update-index' refuses an attempt to add `path/file`.
 	Similarly if a file `path/file` exists, a file `path`
-	cannot be added.  With --replace flag, existing entries
+	cannot be added.  With `--replace` flag, existing entries
 	that conflict with the entry being added are
 	automatically removed with warning messages.
 
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index 48b6683071..3c3da97c29 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -37,7 +37,7 @@ them and update them as a regular file (i.e. it will allow the
 filesystem to follow them, but will overwrite such a symlink to
 somewhere else with a regular filename).
 
-If --no-deref is given, <ref> itself is overwritten, rather than
+If `--no-deref` is given, <ref> itself is overwritten, rather than
 the result of following the symbolic pointers.
 
 In general, using
@@ -164,12 +164,12 @@ stored in <ref>, "newsha1" is the 40 character hexadecimal value of
 <newvalue> and "committer" is the committer's name, email address
 and date in the standard Git committer ident format.
 
-Optionally with -m:
+Optionally with `-m`:
 
     oldsha1 SP newsha1 SP committer TAB message LF
 
 Where all fields are as described above and "message" is the
-value supplied to the -m option.
+value supplied to the `-m` option.
 
 An update will fail (without changing <ref>) if the current user is
 unable to create a new log file, append to the existing log file
diff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt
index 61ca6d04c2..e1e537fcfb 100644
--- a/Documentation/git-verify-pack.txt
+++ b/Documentation/git-verify-pack.txt
@@ -38,7 +38,7 @@ OPTIONS
 
 OUTPUT FORMAT
 -------------
-When specifying the -v option the format used is:
+When specifying the `-v` option the format used is:
 
 	SHA-1 type size size-in-packfile offset-in-packfile
 
diff --git a/Documentation/git-web--browse.txt b/Documentation/git-web--browse.txt
index 8d162b56c5..d53b2570df 100644
--- a/Documentation/git-web--browse.txt
+++ b/Documentation/git-web--browse.txt
@@ -62,7 +62,7 @@ CONF.VAR (from -c option) and web.browser
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The web browser can be specified using a configuration variable passed
-with the -c (or --config) command-line option, or the `web.browser`
+with the `-c` (or `--config`) command-line option, or the `web.browser`
 configuration variable if the former is not used.
 
 browser.<tool>.path
diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt
index 8b63ceb00e..798a43965b 100644
--- a/Documentation/git-whatchanged.txt
+++ b/Documentation/git-whatchanged.txt
@@ -35,7 +35,7 @@ Examples
 `git whatchanged --since="2 weeks ago" -- gitk`::
 
 	Show the changes during the last two weeks to the file 'gitk'.
-	The "--" is necessary to avoid confusion with the *branch* named
+	The `--` is necessary to avoid confusion with the *branch* named
 	'gitk'
 
 GIT
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 3a9c44987f..fc49a4fd42 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -566,9 +566,9 @@ Git Commits
 Git Diffs
 ~~~~~~~~~
 `GIT_DIFF_OPTS`::
-	Only valid setting is "--unified=??" or "-u??" to set the
+	Only valid setting is `--unified=??` or `-u??` to set the
 	number of context lines shown when a unified diff is created.
-	This takes precedence over any "-U" or "--unified" option
+	This takes precedence over any `-U` or `--unified` option
 	value passed on the Git diff command line.
 
 `GIT_EXTERNAL_DIFF`::
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index c0b95256cc..633439702f 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -941,7 +941,7 @@ branch head.  Please see linkgit:gitrevisions[7] if you want to
 see more complex cases.
 
 [NOTE]
-Without the '--more=1' option, 'git show-branch' would not output the
+Without the `--more=1` option, 'git show-branch' would not output the
 '[master^]' commit, as '[mybranch]' commit is a common ancestor of
 both 'master' and 'mybranch' tips.  Please see linkgit:git-show-branch[1]
 for details.
diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
index 0d57f86abc..fbc458c3e5 100644
--- a/Documentation/gitdiffcore.txt
+++ b/Documentation/gitdiffcore.txt
@@ -55,7 +55,7 @@ is under consideration.
 
 The result of comparison is passed from these commands to what is
 internally called "diffcore", in a format similar to what is output
-when the -p option is not used.  E.g.
+when the `-p` option is not used.  E.g.
 
 ------------------------------------------------
 in-place edit  :100644 100644 bcd1234... 0123456... M file0
@@ -89,7 +89,7 @@ diffcore-break: For Splitting Up Complete Rewrites
 --------------------------------------------------
 
 The second transformation in the chain is diffcore-break, and is
-controlled by the -B option to the 'git diff-{asterisk}' commands.  This is
+controlled by the `-B` option to the 'git diff-{asterisk}' commands.  This is
 used to detect a filepair that represents "complete rewrite" and
 break such filepair into two filepairs that represent delete and
 create.  E.g.  If the input contained this filepair:
@@ -117,14 +117,14 @@ score defaults to 50% of the size of the smaller of the original
 and the result (i.e. if the edit shrinks the file, the size of
 the result is used; if the edit lengthens the file, the size of
 the original is used), and can be customized by giving a number
-after "-B" option (e.g. "-B75" to tell it to use 75%).
+after `-B` option (e.g. `-B75` to tell it to use 75%).
 
 
 diffcore-rename: For Detecting Renames and Copies
 -------------------------------------------------
 
 This transformation is used to detect renames and copies, and is
-controlled by the -M option (to detect renames) and the -C option
+controlled by the `-M` option (to detect renames) and the `-C` option
 (to detect copies as well) to the 'git diff-{asterisk}' commands.  If the
 input contained these filepairs:
 
@@ -141,9 +141,9 @@ merges these filepairs and creates:
 :100644 100644 0123456... 0123456... R100 fileX file0
 ------------------------------------------------
 
-When the "-C" option is used, the original contents of modified files,
+When the `-C` option is used, the original contents of modified files,
 and deleted files (and also unmodified files, if the
-"--find-copies-harder" option is used) are considered as candidates
+`--find-copies-harder` option is used) are considered as candidates
 of the source files in rename/copy operation.  If the input were like
 these filepairs, that talk about a modified file fileY and a newly
 created file file0:
@@ -166,7 +166,7 @@ In both rename and copy detection, the same "extent of changes"
 algorithm used in diffcore-break is used to determine if two
 files are "similar enough", and can be customized to use
 a similarity score different from the default of 50% by giving a
-number after the "-M" or "-C" option (e.g. "-M8" to tell it to use
+number after the `-M` or `-C` option (e.g. `-M8` to tell it to use
 8/10 = 80%).
 
 Note that when rename detection is on but both copy and break
@@ -189,7 +189,7 @@ preliminary pass; so if there are several remaining ext.txt files
 throughout the directory hierarchy after exact rename detection, this
 preliminary step may be skipped for those files.
 
-Note.  When the "-C" option is used with `--find-copies-harder`
+Note.  When the `-C` option is used with `--find-copies-harder`
 option, 'git diff-{asterisk}' commands feed unmodified filepairs to
 diffcore mechanism as well as modified ones.  This lets the copy
 detector consider unmodified files as copy source candidates at
@@ -222,13 +222,13 @@ transformation merges them back into the original
 The "extent of changes" parameter can be tweaked from the
 default 80% (that is, unless more than 80% of the original
 material is deleted, the broken pairs are merged back into a
-single modification) by giving a second number to -B option,
+single modification) by giving a second number to `-B` option,
 like these:
 
-* -B50/60 (give 50% "break score" to diffcore-break, use 60%
+* `-B50/60` (give 50% "break score" to diffcore-break, use 60%
   for diffcore-merge-broken).
 
-* -B/60 (the same as above, since diffcore-break defaults to 50%).
+* `-B/60` (the same as above, since diffcore-break defaults to 50%).
 
 Note that earlier implementation left a broken pair as a separate
 creation and deletion patches.  This was an unnecessary hack and
@@ -245,10 +245,10 @@ diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
 
 This transformation limits the set of filepairs to those that change
 specified strings between the preimage and the postimage in a certain
-way.  -S<block of text> and -G<regular expression> options are used to
+way.  `-S<block of text>` and `-G<regular expression>` options are used to
 specify different ways these strings are sought.
 
-"-S<block of text>" detects filepairs whose preimage and postimage
+`-S<block of text>` detects filepairs whose preimage and postimage
 have different number of occurrences of the specified block of text.
 By definition, it will not detect in-file moves.  Also, when a
 changeset moves a file wholesale without affecting the interesting
@@ -258,7 +258,7 @@ rename-detected filepair).  When used with `--pickaxe-regex`, treat
 the <block of text> as an extended POSIX regular expression to match,
 instead of a literal string.
 
-"-G<regular expression>" (mnemonic: grep) detects filepairs whose
+`-G<regular expression>` (mnemonic: grep) detects filepairs whose
 textual diff has an added or a deleted line that matches the given
 regular expression.  This means that it will detect in-file (or what
 rename-detection considers the same file) moves, which is noise.  The
@@ -277,7 +277,7 @@ diffcore-order: For Sorting the Output Based on Filenames
 ---------------------------------------------------------
 
 This is used to reorder the filepairs according to the user's
-(or project's) taste, and is controlled by the -O option to the
+(or project's) taste, and is controlled by the `-O` option to the
 'git diff-{asterisk}' commands.
 
 This takes a text file each of whose lines is a shell glob
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index d50e9ed10e..6ceeae227c 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -112,7 +112,7 @@ include::line-range-options.txt[]
 <path>...::
 
 	Limit commits to the ones touching files in the given paths. Note, to
-	avoid ambiguity with respect to revision names use "--" to separate the paths
+	avoid ambiguity with respect to revision names use `--` to separate the paths
 	from any preceding options.
 
 gitk-specific options
@@ -130,7 +130,7 @@ gitk-specific options
 --select-commit=<ref>::
 
 	Select the specified commit after loading the graph.
-	Default behavior is equivalent to specifying '--select-commit=HEAD'.
+	Default behavior is equivalent to specifying `--select-commit=HEAD`.
 
 Examples
 --------
@@ -142,7 +142,7 @@ gitk v2.6.12.. include/scsi drivers/scsi::
 gitk --since="2 weeks ago" \-- gitk::
 
 	Show the changes during the last two weeks to the file 'gitk'.
-	The "--" is necessary to avoid confusion with the *branch* named
+	The `--` is necessary to avoid confusion with the *branch* named
 	'gitk'
 
 gitk --max-count=100 --all \-- Makefile::
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index 8bdb7d0bd3..e1e09070ad 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -318,7 +318,7 @@ index a042389..513feba 100644
 ------------------------------------------------
 
 At any time, we can create a new commit using 'git commit' (without
-the "-a" option), and verify that the state committed only includes the
+the `-a` option), and verify that the state committed only includes the
 changes stored in the index file, not the additional change that is
 still only in our working tree:
 
@@ -336,7 +336,7 @@ index 513feba..ba3da7b 100644
 ------------------------------------------------
 
 So by default 'git commit' uses the index to create the commit, not
-the working tree; the "-a" option to commit tells it to first update
+the working tree; the `-a` option to commit tells it to first update
 the index with all changes in the working tree.
 
 Finally, it's worth looking at the effect of 'git add' on the index
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 59ef5cef1f..ff366cc752 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -95,13 +95,13 @@ $ git add file1 file2 file3
 ------------------------------------------------
 
 You are now ready to commit.  You can see what is about to be committed
-using 'git diff' with the --cached option:
+using 'git diff' with the `--cached` option:
 
 ------------------------------------------------
 $ git diff --cached
 ------------------------------------------------
 
-(Without --cached, 'git diff' will show you any changes that
+(Without `--cached`, 'git diff' will show you any changes that
 you've made but not yet added to the index.)  You can also get a brief
 summary of the situation with 'git status':
 
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index 7963a79ba9..181c543a64 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -459,14 +459,14 @@ $fallback_encoding::
 
 @diff_opts::
 	Rename detection options for git-diff and git-diff-tree. The default is
-	(\'-M'); set it to (\'-C') or (\'-C', \'-C') to also detect copies,
-	or set it to () i.e. empty list if you don't want to have renames
+	`('-M')`; set it to `('-C')` or `('-C', '-C')` to also detect copies,
+	or set it to `()` i.e. empty list if you don't want to have renames
 	detection.
 +
 *Note* that rename and especially copy detection can be quite
 CPU-intensive.  Note also that non Git tools can have problems with
 patches generated with options mentioned above, especially when they
-involve file copies (\'-C') or criss-cross renames (\'-B').
+involve file copies `('-C')` or criss-cross renames `('-B')`.
 
 
 Some optional features and policies
diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt
index a3e5595a56..29b15a1173 100644
--- a/Documentation/howto/revert-branch-rebase.txt
+++ b/Documentation/howto/revert-branch-rebase.txt
@@ -54,7 +54,7 @@ since then.  I just limited the output to the first handful using
 Now I know 'master^2~4' (pronounce it as "find the second parent of
 the 'master', and then go four generations back following the first
 parent") is the one I would want to revert.  Since I also want to say
-why I am reverting it, the '-n' flag is given to 'git revert'.  This
+why I am reverting it, the `-n` flag is given to 'git revert'.  This
 prevents it from actually making a commit, and instead 'git revert'
 leaves the commit log message it wanted to use in '.msg' file:
 
diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt
index bfe6f9b500..7a34937da0 100644
--- a/Documentation/howto/setup-git-server-over-http.txt
+++ b/Documentation/howto/setup-git-server-over-http.txt
@@ -163,7 +163,7 @@ Create this file by
       $ htpasswd -c /etc/apache2/passwd.git <user>
 
 You will be asked a password, and the file is created. Subsequent calls
-to htpasswd should omit the '-c' option, since you want to append to the
+to htpasswd should omit the `-c` option, since you want to append to the
 existing file.
 
 You need to restart Apache.
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index eb0aabd396..bf43c33d27 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,16 +1,16 @@
 --commit::
 --no-commit::
 	Perform the merge and commit the result. This option can
-	be used to override --no-commit.
+	be used to override `--no-commit`.
 +
-With --no-commit perform the merge and stop just before creating
+With `--no-commit` perform the merge and stop just before creating
 a merge commit, to give the user a chance to inspect and further
 tweak the merge result before committing.
 +
 Note that fast-forward updates do not create a merge commit and
-therefore there is no way to stop those merges with --no-commit.
+therefore there is no way to stop those merges with `--no-commit`.
 Thus, if you want to ensure your branch is not changed or updated
-by the merge command, use --no-ff with --no-commit.
+by the merge command, use `--no-ff` with `--no-commit`.
 
 --edit::
 -e::
@@ -74,7 +74,7 @@ When not possible, refuse to merge and exit with a non-zero status.
 	one-line descriptions from at most <n> actual commits that are being
 	merged. See also linkgit:git-fmt-merge-msg[1].
 +
-With --no-log do not list one-line descriptions from the
+With `--no-log` do not list one-line descriptions from the
 actual commits being merged.
 
 include::signoff-option.txt[]
@@ -85,7 +85,7 @@ include::signoff-option.txt[]
 	Show a diffstat at the end of the merge. The diffstat is also
 	controlled by the configuration option merge.stat.
 +
-With -n or --no-stat do not show a diffstat at the end of the
+With `-n` or `--no-stat` do not show a diffstat at the end of the
 merge.
 
 --squash::
@@ -98,10 +98,10 @@ merge.
 	the current branch whose effect is the same as merging another
 	branch (or more in case of an octopus).
 +
-With --no-squash perform the merge and commit the result. This
-option can be used to override --squash.
+With `--no-squash` perform the merge and commit the result. This
+option can be used to override `--squash`.
 +
-With --squash, --commit is not allowed, and will fail.
+With `--squash`, `--commit` is not allowed, and will fail.
 
 --no-verify::
 	This option bypasses the pre-merge and commit-msg hooks.
@@ -130,13 +130,13 @@ With --squash, --commit is not allowed, and will fail.
 
 --summary::
 --no-summary::
-	Synonyms to --stat and --no-stat; these are deprecated and will be
+	Synonyms to `--stat` and `--no-stat`; these are deprecated and will be
 	removed in the future.
 
 ifndef::git-pull[]
 -q::
 --quiet::
-	Operate quietly. Implies --no-progress.
+	Operate quietly. Implies `--no-progress`.
 
 -v::
 --verbose::
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 45133066e4..d8a755faf1 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -93,8 +93,8 @@ confused as starting a new commit.
 +
 The 'raw' format shows the entire commit exactly as
 stored in the commit object.  Notably, the hashes are
-displayed in full, regardless of whether --abbrev or
---no-abbrev are used, and 'parents' information show the
+displayed in full, regardless of whether `--abbrev` or
+`--no-abbrev` are used, and 'parents' information show the
 true parent commits, without taking grafts or history
 simplification into account. Note that this format affects the way
 commits are displayed, but not the way the diff is shown e.g. with
@@ -144,7 +144,7 @@ The placeholders are:
 	    on the next placeholders until the color is switched
 	    again.
 '%m':: left (`<`), right (`>`) or boundary (`-`) mark
-'%w([<w>[,<i1>[,<i2>]]])':: switch line wrapping, like the -w option of
+'%w([<w>[,<i1>[,<i2>]]])':: switch line wrapping, like the `-w` option of
 			    linkgit:git-shortlog[1].
 '%<(<N>[,trunc|ltrunc|mtrunc])':: make the next placeholder take at
 				  least N columns, padding spaces on
@@ -183,7 +183,7 @@ The placeholders are:
 '%al':: author email local-part (the part before the '@' sign)
 '%aL':: author local-part (see '%al') respecting .mailmap, see
 	linkgit:git-shortlog[1] or linkgit:git-blame[1])
-'%ad':: author date (format respects --date= option)
+'%ad':: author date (format respects `--date=` option)
 '%aD':: author date, RFC2822 style
 '%ar':: author date, relative
 '%at':: author date, UNIX timestamp
@@ -199,14 +199,14 @@ The placeholders are:
 '%cl':: committer email local-part (the part before the '@' sign)
 '%cL':: committer local-part (see '%cl') respecting .mailmap, see
 	linkgit:git-shortlog[1] or linkgit:git-blame[1])
-'%cd':: committer date (format respects --date= option)
+'%cd':: committer date (format respects `--date=` option)
 '%cD':: committer date, RFC2822 style
 '%cr':: committer date, relative
 '%ct':: committer date, UNIX timestamp
 '%ci':: committer date, ISO 8601-like format
 '%cI':: committer date, strict ISO 8601 format
 '%cs':: committer date, short format (`YYYY-MM-DD`)
-'%d':: ref names, like the --decorate option of linkgit:git-log[1]
+'%d':: ref names, like the `--decorate` option of linkgit:git-log[1]
 '%D':: ref names without the " (", ")" wrapping.
 '%(describe[:options])':: human-readable name, like
 			  linkgit:git-describe[1]; empty string for
diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
index 27ddaf84a1..f8c61dd42e 100644
--- a/Documentation/pretty-options.txt
+++ b/Documentation/pretty-options.txt
@@ -6,7 +6,7 @@
 	'full', 'fuller', 'reference', 'email', 'raw', 'format:<string>'
 	and 'tformat:<string>'.  When '<format>' is none of the above,
 	and has '%placeholder' in it, it acts as if
-	'--pretty=tformat:<format>' were given.
+	`--pretty=tformat:<format>` were given.
 +
 See the "PRETTY FORMATS" section for some additional details for each
 format.  When '=<format>' part is omitted, it defaults to 'medium'.
@@ -17,19 +17,19 @@ configuration (see linkgit:git-config[1]).
 --abbrev-commit::
 	Instead of showing the full 40-byte hexadecimal commit object
 	name, show a prefix that names the object uniquely.
-	"--abbrev=<n>" (which also modifies diff output, if it is displayed)
+	`--abbrev=<n>` (which also modifies diff output, if it is displayed)
 	option can be used to specify the minimum length of the prefix.
 +
-This should make "--pretty=oneline" a whole lot more readable for
+This should make `--pretty=oneline` a whole lot more readable for
 people using 80-column terminals.
 
 --no-abbrev-commit::
 	Show the full 40-byte hexadecimal commit object name. This negates
 	`--abbrev-commit`, either explicit or implied by other options such
-	as "--oneline". It also overrides the `log.abbrevCommit` variable.
+	as `--oneline`. It also overrides the `log.abbrevCommit` variable.
 
 --oneline::
-	This is a shorthand for "--pretty=oneline --abbrev-commit"
+	This is a shorthand for `--pretty=oneline --abbrev-commit`
 	used together.
 
 --encoding=<encoding>::
@@ -73,21 +73,21 @@ to display.  The ref can specify the full refname when it begins
 with `refs/notes/`; when it begins with `notes/`, `refs/` and otherwise
 `refs/notes/` is prefixed to form a full name of the ref.
 +
-Multiple --notes options can be combined to control which notes are
-being displayed. Examples: "--notes=foo" will show only notes from
-"refs/notes/foo"; "--notes=foo --notes" will show both notes from
+Multiple `--notes` options can be combined to control which notes are
+being displayed. Examples: `--notes=foo` will show only notes from
+"refs/notes/foo"; `--notes=foo --notes` will show both notes from
 "refs/notes/foo" and from the default notes ref(s).
 
 --no-notes::
 	Do not show notes. This negates the above `--notes` option, by
 	resetting the list of notes refs from which notes are shown.
 	Options are parsed in the order given on the command line, so e.g.
-	"--notes --notes=foo --no-notes --notes=bar" will only show notes
+	`--notes --notes=foo --no-notes --notes=bar` will only show notes
 	from "refs/notes/bar".
 
 --show-notes[=<ref>]::
 --[no-]standard-notes::
-	These options are deprecated. Use the above --notes/--no-notes
+	These options are deprecated. Use the above `--notes`/`--no-notes`
 	options instead.
 endif::git-rev-list[]
 
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index b1c8f86c6e..965cb32f9c 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -885,38 +885,38 @@ ifdef::git-rev-list[]
 	blobs) from the list of printed objects.  The '<filter-spec>'
 	may be one of the following:
 +
-The form '--filter=blob:none' omits all blobs.
+The form `--filter=blob:none` omits all blobs.
 +
-The form '--filter=blob:limit=<n>[kmg]' omits blobs larger than n bytes
+The form `--filter=blob:limit=<n>[kmg]` omits blobs larger than n bytes
 or units.  n may be zero.  The suffixes k, m, and g can be used to name
 units in KiB, MiB, or GiB.  For example, 'blob:limit=1k' is the same
 as 'blob:limit=1024'.
 +
-The form '--filter=sparse:oid=<blob-ish>' uses a sparse-checkout
+The form `--filter=sparse:oid=<blob-ish>` uses a sparse-checkout
 specification contained in the blob (or blob-expression) '<blob-ish>'
 to omit blobs that would not be not required for a sparse checkout on
 the requested refs.
 +
-The form '--filter=tree:<depth>' omits all blobs and trees whose depth
+The form `--filter=tree:<depth>` omits all blobs and trees whose depth
 from the root tree is >= <depth> (minimum depth if an object is located
 at multiple depths in the commits traversed). <depth>=0 will not include
 any trees or blobs unless included explicitly in the command-line (or
-standard input when --stdin is used). <depth>=1 will include only the
+standard input when `--stdin` is used). <depth>=1 will include only the
 tree and blobs which are referenced directly by a commit reachable from
 <commit> or an explicitly-given object. <depth>=2 is like <depth>=1
 while also including trees and blobs one more level removed from an
 explicitly-given commit or tree.
 +
-Note that the form '--filter=sparse:path=<path>' that wants to read
+Note that the form `--filter=sparse:path=<path>` that wants to read
 from an arbitrary path on the filesystem has been dropped for security
 reasons.
 +
-Multiple '--filter=' flags can be specified to combine filters. Only
+Multiple `--filter=` flags can be specified to combine filters. Only
 objects which are accepted by every filter are included.
 +
-The form '--filter=combine:<filter1>+<filter2>+...<filterN>' can also be
+The form `--filter=combine:<filter1>+<filter2>+...<filterN>` can also be
 used to combined several filters, but this is harder than just repeating
-the '--filter' flag and is usually not necessary. Filters are joined by
+the `--filter` flag and is usually not necessary. Filters are joined by
 '{plus}' and individual filters are %-encoded (i.e. URL-encoded).
 Besides the '{plus}' and '%' characters, the following characters are
 reserved and also must be encoded: `~!@#$^&*()[]{}\;",<>?`+&#39;&#96;+
@@ -938,18 +938,18 @@ equivalent.
 	A debug option to help with future "partial clone" development.
 	This option specifies how missing objects are handled.
 +
-The form '--missing=error' requests that rev-list stop with an error if
+The form `--missing=error` requests that rev-list stop with an error if
 a missing object is encountered.  This is the default action.
 +
-The form '--missing=allow-any' will allow object traversal to continue
+The form `--missing=allow-any` will allow object traversal to continue
 if a missing object is encountered.  Missing objects will silently be
 omitted from the results.
 +
-The form '--missing=allow-promisor' is like 'allow-any', but will only
+The form `--missing=allow-promisor` is like 'allow-any', but will only
 allow object traversal to continue for EXPECTED promisor missing objects.
 Unexpected missing objects will raise an error.
 +
-The form '--missing=print' is like 'allow-any', but will also print a
+The form `--missing=print` is like 'allow-any', but will also print a
 list of the missing objects.  Object IDs are prefixed with a ``?'' character.
 
 --exclude-promisor-objects::
@@ -1113,7 +1113,7 @@ This implies the `--topo-order` option by default, but the
 `--date-order` option may also be specified.
 
 --show-linear-break[=<barrier>]::
-	When --graph is not used, all history branches are flattened
+	When `--graph` is not used, all history branches are flattened
 	which can make it hard to see that the two consecutive commits
 	do not belong to a linear branch. This option puts a barrier
 	in between them in that case. If `<barrier>` is specified, it
diff --git a/Documentation/signoff-option.txt b/Documentation/signoff-option.txt
index 12aa2333e4..597d057c6e 100644
--- a/Documentation/signoff-option.txt
+++ b/Documentation/signoff-option.txt
@@ -14,5 +14,5 @@ endif::git-commit[]
 	leadership of the project to which you're contributing to
 	understand how the signoffs are used in that project.
 +
-The --no-signoff option can be used to countermand an earlier --signoff
+The `--no-signoff` option can be used to countermand an earlier `--signoff`
 option on the command line.
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 1c229d7581..c50ddd3120 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -44,13 +44,13 @@ syntaxes may be used:
 
 ifndef::git-clone[]
 These two syntaxes are mostly equivalent, except when cloning, when
-the former implies --local option. See linkgit:git-clone[1] for
+the former implies `--local` option. See linkgit:git-clone[1] for
 details.
 endif::git-clone[]
 
 ifdef::git-clone[]
 These two syntaxes are mostly equivalent, except the former implies
---local option.
+`--local` option.
 endif::git-clone[]
 
 'git clone', 'git fetch' and 'git pull', but not 'git push', will also
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index fd480b8645..0f9a699c09 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -293,7 +293,7 @@ ref: refs/heads/master
 === Examining an old version without creating a new branch
 
 The `git switch` command normally expects a branch head, but will also
-accept an arbitrary commit when invoked with --detach; for example,
+accept an arbitrary commit when invoked with `--detach`; for example,
 you can check out the commit referenced by a tag:
 
 ------------------------------------------------
@@ -305,7 +305,7 @@ changes and commit them, and you can discard any commits you make in this
 state without impacting any branches by performing another switch.
 
 If you want to create a new branch to retain commits you create, you may
-do so (now or later) by using -c with the switch command again. Example:
+do so (now or later) by using `-c` with the switch command again. Example:
 
   git switch -c new_branch_name
 
-- 
2.31.1.133.g84d06cdc06


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [RFC PATCH v1 02/13] doc: typeset branches and remotes in monospace
  2021-04-09  4:02 [RFC PATCH v1 00/13][GSoC] doc: (monospace) apply CodingGuidelines on a large-scale Firmin Martin
  2021-04-09  4:02 ` [RFC PATCH v1 01/13] doc: typeset command-line options in monospace Firmin Martin
@ 2021-04-09  4:02 ` Firmin Martin
  2021-04-09  4:02 ` [RFC PATCH v1 03/13] doc: typeset configuration options " Firmin Martin
                   ` (11 subsequent siblings)
  13 siblings, 0 replies; 20+ messages in thread
From: Firmin Martin @ 2021-04-09  4:02 UTC (permalink / raw)
  To: git; +Cc: Firmin Martin

Wrap branch and remote names with backticks as indicated in the
CodingGuidelines.

Signed-off-by: Firmin Martin <firminmartin24@gmail.com>
---
 Documentation/diff-options.txt         |  2 +-
 Documentation/git-add.txt              | 10 +--
 Documentation/git-am.txt               |  4 +-
 Documentation/git-archimport.txt       |  2 +-
 Documentation/git-bisect-lk2009.txt    | 10 +--
 Documentation/git-bisect.txt           |  6 +-
 Documentation/git-branch.txt           | 22 +++---
 Documentation/git-bundle.txt           |  6 +-
 Documentation/git-check-ref-format.txt |  2 +-
 Documentation/git-checkout.txt         |  2 +-
 Documentation/git-cherry-pick.txt      | 22 +++---
 Documentation/git-cherry.txt           |  4 +-
 Documentation/git-clone.txt            | 16 ++---
 Documentation/git-commit-tree.txt      |  2 +-
 Documentation/git-commit.txt           |  6 +-
 Documentation/git-config.txt           |  2 +-
 Documentation/git-cvsimport.txt        |  8 +--
 Documentation/git-cvsserver.txt        |  2 +-
 Documentation/git-describe.txt         |  6 +-
 Documentation/git-diff-index.txt       |  6 +-
 Documentation/git-diff.txt             | 20 +++---
 Documentation/git-fast-export.txt      | 16 ++---
 Documentation/git-fetch-pack.txt       |  2 +-
 Documentation/git-fetch.txt            |  4 +-
 Documentation/git-filter-branch.txt    |  2 +-
 Documentation/git-fmt-merge-msg.txt    |  4 +-
 Documentation/git-for-each-ref.txt     | 12 ++--
 Documentation/git-format-patch.txt     |  4 +-
 Documentation/git-http-push.txt        |  6 +-
 Documentation/git-log.txt              |  8 +--
 Documentation/git-ls-remote.txt        |  2 +-
 Documentation/git-merge.txt            |  2 +-
 Documentation/git-notes.txt            | 12 ++--
 Documentation/git-p4.txt               |  4 +-
 Documentation/git-pull.txt             |  4 +-
 Documentation/git-push.txt             |  8 +--
 Documentation/git-read-tree.txt        |  4 +-
 Documentation/git-rebase.txt           | 92 +++++++++++++-------------
 Documentation/git-reflog.txt           |  4 +-
 Documentation/git-request-pull.txt     |  2 +-
 Documentation/git-rerere.txt           | 34 +++++-----
 Documentation/git-reset.txt            |  6 +-
 Documentation/git-rev-parse.txt        |  4 +-
 Documentation/git-revert.txt           |  8 +--
 Documentation/git-rm.txt               |  2 +-
 Documentation/git-show-ref.txt         |  2 +-
 Documentation/git-show.txt             |  2 +-
 Documentation/git-stash.txt            |  8 +--
 Documentation/git-status.txt           | 12 ++--
 Documentation/git-submodule.txt        | 28 ++++----
 Documentation/git-svn.txt              | 20 +++---
 Documentation/git-switch.txt           | 10 +--
 Documentation/git-symbolic-ref.txt     |  2 +-
 Documentation/git-tag.txt              |  2 +-
 Documentation/git-update-ref.txt       |  4 +-
 Documentation/git-worktree.txt         |  2 +-
 Documentation/git.txt                  |  4 +-
 Documentation/gitcli.txt               |  2 +-
 Documentation/gitcore-tutorial.txt     | 36 +++++-----
 Documentation/giteveryday.txt          | 16 ++---
 Documentation/githooks.txt             |  8 +--
 Documentation/gitk.txt                 |  2 +-
 Documentation/gitnamespaces.txt        |  2 +-
 Documentation/gitremote-helpers.txt    |  6 +-
 Documentation/gitrepository-layout.txt |  4 +-
 Documentation/gittutorial-2.txt        |  2 +-
 Documentation/gittutorial.txt          | 44 ++++++------
 Documentation/gitweb.txt               |  4 +-
 Documentation/gitworkflows.txt         | 70 ++++++++++----------
 Documentation/glossary-content.txt     | 12 ++--
 Documentation/rev-list-options.txt     |  2 +-
 Documentation/revisions.txt            | 52 +++++++--------
 Documentation/user-manual.txt          | 78 +++++++++++-----------
 73 files changed, 421 insertions(+), 421 deletions(-)

diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 13e0753862..e4ac746428 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -803,7 +803,7 @@ endif::git-format-patch[]
 	Ignore changes to submodules in the diff generation. <when> can be
 	either "none", "untracked", "dirty" or "all", which is the default.
 	Using "none" will consider the submodule modified when it either contains
-	untracked or modified files or its HEAD differs from the commit recorded
+	untracked or modified files or its `HEAD` differs from the commit recorded
 	in the superproject and can be used to override any settings of the
 	'ignore' option in linkgit:git-config[1] or linkgit:gitmodules[5]. When
 	"untracked" is used submodules are not considered dirty when they only
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 6a7cb07a8a..8ec99c5c12 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -256,7 +256,7 @@ The main command loop has 6 subcommands (plus help and quit).
 
 status::
 
-   This shows the change between HEAD and index (i.e. what will be
+   This shows the change between `HEAD` and index (i.e. what will be
    committed if you say `git commit`), and between index and
    working tree files (i.e. what you could stage further before
    `git commit` using `git add`) for each path.  A sample output
@@ -268,7 +268,7 @@ status::
      2:     +403/-35        +1/-1 git-add--interactive.perl
 ------------
 +
-It shows that foo.png has differences from HEAD (but that is
+It shows that foo.png has differences from `HEAD` (but that is
 binary so line count cannot be shown) and there is no
 difference between indexed copy and the working tree
 version (if the working tree version were also different,
@@ -311,7 +311,7 @@ revert::
 
   This has a very similar UI to 'update', and the staged
   information for selected paths are reverted to that of the
-  HEAD version.  Reverting new paths makes them untracked.
+  `HEAD` version.  Reverting new paths makes them untracked.
 
 add untracked::
 
@@ -350,7 +350,7 @@ variable `interactive.singleKey` to `true`.
 diff::
 
   This lets you review what will be committed (i.e. between
-  HEAD and index).
+  `HEAD` and index).
 
 
 EDITING PATCHES
@@ -389,7 +389,7 @@ There are also more complex operations that can be performed. But beware
 that because the patch is applied only to the index and not the working
 tree, the working tree will appear to "undo" the change in the index.
 For example, introducing a new line into the index that is in neither
-the HEAD nor the working tree will stage the new line for commit, but
+the `HEAD` nor the working tree will stage the new line for commit, but
 the line will appear to be reverted in the working tree.
 
 Avoid using these constructs, or do so with extreme caution.
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index decd8ae122..cd56054be0 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -176,7 +176,7 @@ default.   You can use `--no-utf8` to override this.
 	Restore the original branch and abort the patching operation.
 
 --quit::
-	Abort the patching operation but keep HEAD and the index
+	Abort the patching operation but keep `HEAD` and the index
 	untouched.
 
 --show-current-patch[=(diff|raw)]::
@@ -229,7 +229,7 @@ operation is finished, so if you decide to start over from scratch,
 run `git am --abort` before running the command with mailbox
 names.
 
-Before any patches are applied, ORIG_HEAD is set to the tip of the
+Before any patches are applied, `ORIG_HEAD` is set to the tip of the
 current branch.  This is useful if you have problems with multiple
 commits, like running 'git am' on the wrong branch or an error in the
 commits that is more easily fixed by changing the mailbox (e.g.
diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt
index b477e3c495..6e2dec5ef1 100644
--- a/Documentation/git-archimport.txt
+++ b/Documentation/git-archimport.txt
@@ -45,7 +45,7 @@ archives that it imports, it is also possible to specify Git branch names
 manually.  To do so, write a Git branch name after each <archive/branch>
 parameter, separated by a colon.  This way, you can shorten the Arch
 branch names and convert Arch jargon to Git jargon, for example mapping a
-"PROJECT{litdd}devo{litdd}VERSION" branch to "master".
+"PROJECT{litdd}devo{litdd}VERSION" branch to `master`.
 
 Associating multiple Arch branches to one Git branch is possible; the
 result will make the most sense only if no commits are made to the first
diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt
index f3d9566c89..1276424d65 100644
--- a/Documentation/git-bisect-lk2009.txt
+++ b/Documentation/git-bisect-lk2009.txt
@@ -767,8 +767,8 @@ They cannot be on a branch that has no link with the branch of the
 bad commit and yet not be neither one of its ancestor nor one of its
 descendants.
 
-For example, there can be a "main" branch, and a "dev" branch that was
-forked of the main branch at a commit named "D" like this:
+For example, there can be a `main` branch, and a `dev` branch that was
+forked of the `main` branch at a commit named "D" like this:
 
 -------------
 A-B-C-D-E-F-G  <--main
@@ -776,7 +776,7 @@ A-B-C-D-E-F-G  <--main
         H-I-J  <--dev
 -------------
 
-The commit "D" is called a "merge base" for branch "main" and "dev"
+The commit "D" is called a "merge base" for branch `main` and `dev`
 because it's the best common ancestor for these branches for a merge.
 
 Now let's suppose that commit J is bad and commit G is good and that
@@ -794,7 +794,7 @@ H-I-J
 -------------
 
 But what happens if the first bad commit is "B" and if it has been
-fixed in the "main" branch by commit "F"?
+fixed in the `main` branch by commit "F"?
 
 The result of such a bisection would be that we would find that H is
 the first bad commit, when in fact it's B. So that would be wrong!
@@ -1229,7 +1229,7 @@ message or the author. And it can also be used instead of git "grafts"
 to link a repository with another old repository.
 
 In fact it's this last feature that "sold" it to the Git community, so
-it is now in the "master" branch of Git's Git repository and it should
+it is now in the `master` branch of Git's Git repository and it should
 be released in Git 1.6.5 in October or November 2009.
 
 One problem with "git replace" is that currently it stores all the
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index fbb39fbdf5..ff50c66e29 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -98,7 +98,7 @@ Bisect reset
 ~~~~~~~~~~~~
 
 After a bisect session, to clean up the bisection state and return to
-the original HEAD, issue the following command:
+the original `HEAD`, issue the following command:
 
 ------------------------------------------------
 $ git bisect reset
@@ -379,7 +379,7 @@ branch contained broken or non-buildable commits, but the merge itself was OK.
 EXAMPLES
 --------
 
-* Automatically bisect a broken build between v1.2 and HEAD:
+* Automatically bisect a broken build between v1.2 and `HEAD`:
 +
 ------------
 $ git bisect start HEAD v1.2 --      # HEAD is bad, v1.2 is good
@@ -387,7 +387,7 @@ $ git bisect run make                # "make" builds the app
 $ git bisect reset                   # quit the bisect session
 ------------
 
-* Automatically bisect a test failure between origin and HEAD:
+* Automatically bisect a test failure between `origin` and `HEAD`:
 +
 ------------
 $ git bisect start HEAD origin --    # HEAD is bad, origin is good
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 271b4ee34e..fa38fa4dc1 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -175,7 +175,7 @@ This option is only applicable in non-verbose mode.
 	the pattern(s).
 
 --show-current::
-	Print the name of the current branch. In detached HEAD state,
+	Print the name of the current branch. In detached `HEAD` state,
 	nothing is printed.
 
 -v::
@@ -186,7 +186,7 @@ This option is only applicable in non-verbose mode.
 	relationship to upstream branch (if any). If given twice, print
 	the path of the linked worktree (if any) and the name of the upstream
 	branch, as well (see also `git remote show <remote>`).  Note that the
-	current worktree's HEAD will not have its path printed (it will always
+	current worktree's `HEAD` will not have its path printed (it will always
 	be your current directory).
 
 -q::
@@ -250,15 +250,15 @@ start-point is either a local or remote-tracking branch.
 
 --no-contains [<commit>]::
 	Only list branches which don't contain the specified commit
-	(HEAD if not specified). Implies `--list`.
+	(`HEAD` if not specified). Implies `--list`.
 
 --merged [<commit>]::
 	Only list branches whose tips are reachable from the
-	specified commit (HEAD if not specified). Implies `--list`.
+	specified commit (`HEAD` if not specified). Implies `--list`.
 
 --no-merged [<commit>]::
 	Only list branches whose tips are not reachable from the
-	specified commit (HEAD if not specified). Implies `--list`.
+	specified commit (`HEAD` if not specified). Implies `--list`.
 
 <branchname>::
 	The name of the branch to create or delete.
@@ -269,7 +269,7 @@ start-point is either a local or remote-tracking branch.
 <start-point>::
 	The new branch head will point to this commit.  It may be
 	given as a branch name, a commit-id, or a tag.  If this
-	option is omitted, the current HEAD will be used instead.
+	option is omitted, the current `HEAD` will be used instead.
 
 <oldbranch>::
 	The name of an existing branch to rename.
@@ -286,7 +286,7 @@ start-point is either a local or remote-tracking branch.
 	for-each-ref`. Sort order defaults to the value configured for the
 	`branch.sort` variable if exists, or to sorting based on the
 	full refname (including `refs/...` prefix). This lists
-	detached HEAD (if present) first, then local branches and
+	detached `HEAD` (if present) first, then local branches and
 	finally remote-tracking branches. See linkgit:git-config[1].
 
 
@@ -328,10 +328,10 @@ $ git branch -d -r origin/todo origin/html origin/man   <1>
 $ git branch -D test                                    <2>
 ------------
 +
-<1> Delete the remote-tracking branches "todo", "html" and "man". The next
+<1> Delete the remote-tracking branches `todo`, `html` and `man`. The next
     'fetch' or 'pull' will create them again unless you configure them not to.
     See linkgit:git-fetch[1].
-<2> Delete the "test" branch even if the "master" branch (or whichever branch
+<2> Delete the `test` branch even if the `master` branch (or whichever branch
     is currently checked out) does not have all commits from the test branch.
 
 Listing branches from a specific remote::
@@ -365,10 +365,10 @@ serve four related but different purposes:
   contain the specified <commit>.
 
 - `--merged` is used to find all branches which can be safely deleted,
-  since those branches are fully contained by HEAD.
+  since those branches are fully contained by `HEAD`.
 
 - `--no-merged` is used to find branches which are candidates for merging
-  into HEAD, since those branches are not fully contained by HEAD.
+  into `HEAD`, since those branches are not fully contained by `HEAD`.
 
 include::ref-reachability-filters.txt[]
 
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 4f1e59a3b2..20da47cbd6 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -68,7 +68,7 @@ unbundle <file>::
 	'git rev-list' (and containing a named ref, see SPECIFYING REFERENCES
 	below), that specifies the specific objects and references
 	to transport.  For example, `master~10..master` causes the
-	current master reference to be packaged along with all objects
+	current `master` reference to be packaged along with all objects
 	added since its 10th ancestor commit.  There is no explicit
 	limit to the number of references and objects that may be
 	packaged.
@@ -146,7 +146,7 @@ Assume you want to transfer the history from a repository R1 on machine A
 to another repository R2 on machine B.
 For whatever reason, direct connection between A and B is not allowed,
 but we can move data from A to B via some mechanism (CD, email, etc.).
-We want to update R2 with development made on the branch master in R1.
+We want to update R2 with development made on the branch `master` in R1.
 
 To bootstrap the process, you can first create a bundle that does not have
 any basis. You can use a tag to remember up to what commit you last
@@ -167,7 +167,7 @@ create a new repository on machine B by cloning from it:
 machineB$ git clone -b master /home/me/tmp/file.bundle R2
 ----------------
 
-This will define a remote called "origin" in the resulting repository that
+This will define a remote called `origin` in the resulting repository that
 lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will
 have an entry like this:
 
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index ee6a4144fb..f39622c0da 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -80,7 +80,7 @@ reference name expressions (see linkgit:gitrevisions[7]):
 With the `--branch` option, the command takes a name and checks if
 it can be used as a valid branch name (e.g. when creating a new
 branch). But be cautious when using the
-previous checkout syntax that may refer to a detached HEAD state.
+previous checkout syntax that may refer to a detached `HEAD` state.
 The rule `git check-ref-format --branch $name` implements
 may be stricter than what `git check-ref-format refs/heads/$name`
 says (e.g. a dash may appear at the beginning of a ref component,
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 3336b8dace..192dbfe9b0 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -189,7 +189,7 @@ one for the purposes of disambiguation, even if the `<branch>` isn't
 unique across all remotes. Set it to
 e.g. `checkout.defaultRemote=origin` to always checkout remote
 branches from there if `<branch>` is ambiguous but exists on the
-'origin' remote. See also `checkout.defaultRemote` in
+`origin` remote. See also `checkout.defaultRemote` in
 linkgit:git-config[1].
 +
 `--guess` is the default behavior. Use `--no-guess` to disable it.
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 0127f56204..6069cc77a0 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -17,7 +17,7 @@ DESCRIPTION
 
 Given one or more existing commits, apply the change each one
 introduces, recording a new commit for each.  This requires your
-working tree to be clean (no modifications from the HEAD commit).
+working tree to be clean (no modifications from the `HEAD` commit).
 
 When it is not obvious how to apply a change, the following
 happens:
@@ -96,7 +96,7 @@ OPTIONS
 	each named commit to your working tree and the index,
 	without making any commit.  In addition, when this
 	option is used, your index does not have to match the
-	HEAD commit.  The cherry-pick is done against the
+	`HEAD` commit.  The cherry-pick is done against the
 	beginning state of your index.
 +
 This is useful when cherry-picking more than one commits'
@@ -117,7 +117,7 @@ effect to your index in a row.
 	earlier `--gpg-sign`.
 
 --ff::
-	If the current HEAD is the same as the parent of the
+	If the current `HEAD` is the same as the parent of the
 	cherry-pick'ed commit, then a fast forward to this commit will
 	be performed.
 
@@ -176,13 +176,13 @@ EXAMPLES
 `git cherry-pick ^HEAD master`::
 
 	Apply the changes introduced by all commits that are ancestors
-	of master but not of HEAD to produce new commits.
+	of `master` but not of `HEAD` to produce new commits.
 
 `git cherry-pick maint next ^master`::
 `git cherry-pick maint master..next`::
 
 	Apply the changes introduced by all commits that are
-	ancestors of maint or next, but not master or any of its
+	ancestors of `maint` or `next`, but not `master` or any of its
 	ancestors.  Note that the latter does not mean `maint` and
 	everything between `master` and `next`; specifically,
 	`maint` will not be used if it is included in `master`.
@@ -190,27 +190,27 @@ EXAMPLES
 `git cherry-pick master~4 master~2`::
 
 	Apply the changes introduced by the fifth and third last
-	commits pointed to by master and create 2 new commits with
+	commits pointed to by `master` and create 2 new commits with
 	these changes.
 
 `git cherry-pick -n master~1 next`::
 
 	Apply to the working tree and the index the changes introduced
-	by the second last commit pointed to by master and by the last
+	by the second last commit pointed to by `master` and by the last
 	commit pointed to by next, but do not create any commit with
 	these changes.
 
 `git cherry-pick --ff ..next`::
 
-	If history is linear and HEAD is an ancestor of next, update
-	the working tree and advance the HEAD pointer to match next.
+	If history is linear and `HEAD` is an ancestor of next, update
+	the working tree and advance the `HEAD` pointer to match next.
 	Otherwise, apply the changes introduced by those commits that
-	are in next but not HEAD to the current branch, creating a new
+	are in next but not `HEAD` to the current branch, creating a new
 	commit for each new change.
 
 `git rev-list --reverse master -- README | git cherry-pick -n --stdin`::
 
-	Apply the changes introduced by all commits on the master
+	Apply the changes introduced by all commits on the `master`
 	branch that touched README to the working tree and index,
 	so the result can be inspected and made into a single new
 	commit if suitable.
diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt
index 0ea921a593..4374f398fa 100644
--- a/Documentation/git-cherry.txt
+++ b/Documentation/git-cherry.txt
@@ -31,10 +31,10 @@ OPTIONS
 
 <upstream>::
 	Upstream branch to search for equivalent commits.
-	Defaults to the upstream branch of HEAD.
+	Defaults to the upstream branch of `HEAD`.
 
 <head>::
-	Working branch; defaults to HEAD.
+	Working branch; defaults to `HEAD`.
 
 <limit>::
 	Do not report commits up to (and including) limit.
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 22334771d1..8cd602a852 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -30,8 +30,8 @@ currently active branch.
 
 After the clone, a plain `git fetch` without arguments will update
 all the remote-tracking branches, and a `git pull` without
-arguments will in addition merge the remote master branch into the
-current master branch, if any (this is untrue when `--single-branch`
+arguments will in addition merge the remote `master` branch into the
+current `master` branch, if any (this is untrue when `--single-branch`
 is given; see below).
 
 This default configuration is achieved by creating references to
@@ -147,7 +147,7 @@ objects from the source repository into a pack in the cloned repository.
 
 -n::
 --no-checkout::
-	No checkout of HEAD is performed after the clone is complete.
+	No checkout of `HEAD` is performed after the clone is complete.
 
 --[no-]reject-shallow::
 	Fail if the source repository is a shallow repository.
@@ -198,11 +198,11 @@ objects from the source repository into a pack in the cloned repository.
 
 -b <name>::
 --branch <name>::
-	Instead of pointing the newly created HEAD to the branch pointed
-	to by the cloned repository's HEAD, point to `<name>` branch
+	Instead of pointing the newly created `HEAD` to the branch pointed
+	to by the cloned repository's `HEAD`, point to `<name>` branch
 	instead. In a non-bare repository, this is the branch that will
 	be checked out.
-	`--branch` can also take tags and detaches the HEAD at that commit
+	`--branch` can also take tags and detaches the `HEAD` at that commit
 	in the resulting repository.
 
 -u <upload-pack>::
@@ -224,7 +224,7 @@ objects from the source repository into a pack in the cloned repository.
 	linkgit:git-config[1] (e.g., `core.eol=true`). If multiple
 	values are given for the same key, each value will be written to
 	the config file. This makes it safe, for example, to add
-	additional fetch refspecs to the origin remote.
+	additional fetch refspecs to the `origin` remote.
 +
 Due to limitations of the current implementation, some configuration
 variables do not take effect until after the initial fetch and checkout.
@@ -253,7 +253,7 @@ corresponding `--mirror` and `--no-tags` options instead.
 	branch remote's `HEAD` points at.
 	Further fetches into the resulting repository will only update the
 	remote-tracking branch for the branch this option was used for the
-	initial cloning.  If the HEAD at the remote did not point at any
+	initial cloning.  If the `HEAD` at the remote did not point at any
 	branch when `--single-branch` clone was made, no remote-tracking
 	branch is created.
 
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
index 2e2c581098..b76a825c94 100644
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -36,7 +36,7 @@ While a tree represents a particular directory state of a working
 directory, a commit represents that state in "time", and explains how
 to get there.
 
-Normally a commit would identify a new "HEAD" state, and while Git
+Normally a commit would identify a new `HEAD` state, and while Git
 doesn't care where you save the note about that state, in practice we
 tend to just write the result to the file that is pointed at by
 `.git/HEAD`, so that we can always see what the last committed
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 6d0d663b50..f507ae00a1 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -21,9 +21,9 @@ DESCRIPTION
 -----------
 Create a new commit containing the current contents of the index and
 the given log message describing the changes. The new commit is a
-direct child of HEAD, usually the tip of the current branch, and the
+direct child of `HEAD`, usually the tip of the current branch, and the
 branch is updated to point to it (unless no branch is associated with
-the working tree, in which case HEAD is "detached" as described in
+the working tree, in which case `HEAD` is "detached" as described in
 linkgit:git-checkout[1]).
 
 The content to be committed can be specified in several ways:
@@ -352,7 +352,7 @@ configuration variable documented in linkgit:git-config[1].
 
 -v::
 --verbose::
-	Show unified diff between the HEAD commit and what
+	Show unified diff between the `HEAD` commit and what
 	would be committed at the bottom of the commit message
 	template to help the user describe the commit by reminding
 	what changes the commit has.
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index b93394ea45..e6d70ffda1 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -148,7 +148,7 @@ See also <<FILES>>.
 --blob blob::
 	Similar to `--file` but use the given blob instead of a file. E.g.
 	you can use 'master:.gitmodules' to read values from the file
-	'.gitmodules' in the master branch. See "SPECIFYING REVISIONS"
+	'.gitmodules' in the `master` branch. See "SPECIFYING REVISIONS"
 	section in linkgit:gitrevisions[7] for a more complete list of
 	ways to spell blob names.
 
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 143c726511..95fa94de74 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -35,7 +35,7 @@ Please see the section <<issues,ISSUES>> for further reference.
 
 You should *never* do any work of your own on the branches that are
 created by 'git cvsimport'.  By default initial import will create and populate a
-"master" branch from the CVS repository's main branch which you're free
+`master` branch from the CVS repository's main branch which you're free
 to work with; after that, you need to 'git merge' incremental imports, or
 any CVS branches, yourself.  It is advisable to specify a named remote via
 `-r` to separate and protect the incoming branches.
@@ -71,11 +71,11 @@ OPTIONS
 -r <remote>::
 	The Git remote to import this CVS repository into.
 	Moves all CVS branches into remotes/<remote>/<branch>
-	akin to the way 'git clone' uses 'origin' by default.
+	akin to the way 'git clone' uses `origin` by default.
 
 -o <branch-for-HEAD>::
 	When no remote is specified (via `-r`) the `HEAD` branch
-	from CVS is imported to the 'origin' branch within the Git
+	from CVS is imported to the `origin` branch within the Git
 	repository, as `HEAD` already has a special meaning for Git.
 	When a remote is specified the `HEAD` branch is named
 	remotes/<remote>/master mirroring 'git clone' behaviour.
@@ -200,7 +200,7 @@ Problems related to timestamps:
    to be used for ordering commits changes may show up in the wrong
    order.
  * If any files were ever "cvs import"ed more than once (e.g., import of
-   more than one vendor release) the HEAD contains the wrong content.
+   more than one vendor release) the `HEAD` contains the wrong content.
  * If the timestamp order of different files cross the revision order
    within the commit matching time window the order of commits may be
    wrong.
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 955bae46c9..c6a926d8d2 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -199,7 +199,7 @@ allowing access over SSH.
 5. Clients should now be able to check out the project. Use the CVS 'module'
    name to indicate what Git 'head' you want to check out.  This also sets the
    name of your newly checked-out directory, unless you tell it otherwise with
-   `-d <dir_name>`.  For example, this checks out 'master' branch to the
+   `-d <dir_name>`.  For example, this checks out `master` branch to the
    `project-master` directory:
 +
 ------
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index a3f015743b..7d2649c477 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -30,17 +30,17 @@ If the given object refers to a blob, it will be described
 as `<commit-ish>:<path>`, such that the blob can be found
 at `<path>` in the `<commit-ish>`, which itself describes the
 first commit in which this blob occurs in a reverse revision walk
-from HEAD.
+from `HEAD`.
 
 OPTIONS
 -------
 <commit-ish>...::
-	Commit-ish object names to describe.  Defaults to HEAD if omitted.
+	Commit-ish object names to describe.  Defaults to `HEAD` if omitted.
 
 --dirty[=<mark>]::
 --broken[=<mark>]::
 	Describe the state of the working tree.  When the working
-	tree matches HEAD, the output is the same as "git describe
+	tree matches `HEAD`, the output is the same as "git describe
 	HEAD".  If the working tree has local modification "-dirty"
 	is appended to it.  If a repository is corrupt and Git
 	cannot determine if there is local modification, Git will
diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt
index 27acb31cbf..10e79a29aa 100644
--- a/Documentation/git-diff-index.txt
+++ b/Documentation/git-diff-index.txt
@@ -31,7 +31,7 @@ include::diff-options.txt[]
 
 --merge-base::
 	Instead of comparing <tree-ish> directly, use the merge base
-	between <tree-ish> and HEAD instead.  <tree-ish> must be a
+	between <tree-ish> and `HEAD` instead.  <tree-ish> must be a
 	commit.
 
 -m::
@@ -53,7 +53,7 @@ CACHED MODE
 -----------
 If `--cached` is specified, it allows you to ask:
 
-	show me the differences between HEAD and the current index
+	show me the differences between `HEAD` and the current index
 	contents (the ones I'd write using 'git write-tree')
 
 For example, let's say that you have worked on your working directory, updated
@@ -89,7 +89,7 @@ the more useful of the two in that what it does can't be emulated with
 a 'git write-tree' + 'git diff-tree'. Thus that's the default mode.
 The non-cached version asks the question:
 
-  show me the differences between HEAD and the currently checked out
+  show me the differences between `HEAD` and the currently checked out
   tree - index contents _and_ files that aren't up to date
 
 which is obviously a very useful question too, since that tells you what
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 9f4b46c910..33a47958bc 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -45,20 +45,20 @@ files on disk.
 	This form is to view the changes you staged for the next
 	commit relative to the named <commit>.  Typically you
 	would want comparison with the latest commit, so if you
-	do not give <commit>, it defaults to HEAD.
-	If HEAD does not exist (e.g. unborn branches) and
+	do not give <commit>, it defaults to `HEAD`.
+	If `HEAD` does not exist (e.g. unborn branches) and
 	<commit> is not given, it shows all staged changes.
 	`--staged` is a synonym of `--cached`.
 +
 If `--merge-base` is given, instead of using <commit>, use the merge base
-of <commit> and HEAD.  `git diff --merge-base A` is equivalent to
+of <commit> and `HEAD`.  `git diff --merge-base A` is equivalent to
 `git diff $(git merge-base A HEAD)`.
 
 'git diff' [<options>] <commit> [--] [<path>...]::
 
 	This form is to view the changes you have in your
 	working tree relative to the named <commit>.  You can
-	use HEAD to compare it with the latest commit, or a
+	use `HEAD` to compare it with the latest commit, or a
 	branch name to compare with the tip of a different
 	branch.
 
@@ -85,7 +85,7 @@ If `--merge-base` is given, use the merge base of the two commits for the
 	This is synonymous to the earlier form (without the `..`) for
 	viewing the changes between two arbitrary <commit>.  If <commit> on
 	one side is omitted, it will have the same effect as
-	using HEAD instead.
+	using `HEAD` instead.
 
 'git diff' [<options>] <commit>\...<commit> [--] [<path>...]::
 
@@ -93,7 +93,7 @@ If `--merge-base` is given, use the merge base of the two commits for the
 	and up to the second <commit>, starting at a common ancestor
 	of both <commit>.  `git diff A...B` is equivalent to
 	`git diff $(git merge-base A B) B`.  You can omit any one
-	of <commit>, which has the same effect as using HEAD instead.
+	of <commit>, which has the same effect as using `HEAD` instead.
 
 Just in case you are doing something exotic, it should be
 noted that all of the <commit> in the above description, except
@@ -165,8 +165,8 @@ $ git diff HEAD^ HEAD      <3>
 ------------
 +
 <1> Instead of using the tip of the current branch, compare with the
-    tip of "test" branch.
-<2> Instead of comparing with the tip of "test" branch, compare with
+    tip of `test` branch.
+<2> Instead of comparing with the tip of `test` branch, compare with
     the tip of the current branch, but limit the comparison to the
     file "test".
 <3> Compare the version before the last commit and the last commit.
@@ -179,9 +179,9 @@ $ git diff topic..master   <2>
 $ git diff topic...master  <3>
 ------------
 +
-<1> Changes between the tips of the topic and the master branches.
+<1> Changes between the tips of the `topic` and the `master` branches.
 <2> Same as above.
-<3> Changes that occurred on the master branch since when the topic
+<3> Changes that occurred on the `master` branch since when the `topic`
     branch was started off it.
 
 Limiting the diff output::
diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
index a1c02918f9..3a6a77abac 100644
--- a/Documentation/git-fast-export.txt
+++ b/Documentation/git-fast-export.txt
@@ -126,10 +126,10 @@ by keeping the marks the same across runs.
 
 --reference-excluded-parents::
 	By default, running a command such as `git fast-export
-	master~5..master` will not include the commit master{tilde}5
-	and will make master{tilde}4 no longer have master{tilde}5 as
-	a parent (though both the old master{tilde}4 and new
-	master{tilde}4 will have all the same files).  Use
+	master~5..master` will not include the commit `master~5`
+	and will make `master~4` no longer have `master~5` as
+	a parent (though both the old `master~4` and new
+	`master~4` will have all the same files).  Use
 	`--reference-excluded-parents` to instead have the stream
 	refer to commits in the excluded range of history by their
 	sha1sum.  Note that the resulting stream can only be used by a
@@ -158,10 +158,10 @@ by keeping the marks the same across runs.
 	A list of arguments, acceptable to 'git rev-parse' and
 	'git rev-list', that specifies the specific objects and references
 	to export.  For example, `master~10..master` causes the
-	current master reference to be exported along with all objects
+	current `master` reference to be exported along with all objects
 	added since its 10th ancestor commit and (unless the
 	`--reference-excluded-parents` option is specified) all files
-	common to master{tilde}9 and master{tilde}10.
+	common to `master~9` and `master~10`.
 
 EXAMPLES
 --------
@@ -180,8 +180,8 @@ $ git fast-export master~5..master |
 	git fast-import
 -----------------------------------------------------
 
-This makes a new branch called 'other' from 'master~5..master'
-(i.e. if 'master' has linear history, it will take the last 5 commits).
+This makes a new branch called `other` from `master~5`..`master`
+(i.e. if `master` has linear history, it will take the last 5 commits).
 
 Note that this assumes that none of the blobs and commit messages
 referenced by that revision range contains the string
diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
index 88c2b9d426..1f48f89e3e 100644
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -116,7 +116,7 @@ be in a separate packet, and the list must end with a flush packet.
 
 <refs>...::
 	The remote heads to update from. This is relative to
-	$GIT_DIR (e.g. "HEAD", "refs/heads/master").  When
+	$GIT_DIR (e.g. `HEAD`, "refs/heads/master").  When
 	unspecified, update from all heads the remote side has.
 +
 If the remote has enabled the options `uploadpack.allowTipSHA1InWant`,
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 85b073a61a..a5ecf00db3 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -87,10 +87,10 @@ This configuration is used in two ways:
   <refspec>s given on the command line determine what are to be
   fetched (e.g. `master` in the example,
   which is a short-hand for `master:`, which in turn means
-  "fetch the 'master' branch but I do not explicitly say what
+  "fetch the `master` branch but I do not explicitly say what
   remote-tracking branch to update with it from the command line"),
   and the example command will
-  fetch _only_ the 'master' branch.  The `remote.<repository>.fetch`
+  fetch _only_ the `master` branch.  The `remote.<repository>.fetch`
   values determine which
   remote-tracking branch, if any, is updated.  When used in this
   way, the `remote.<repository>.fetch` values do not have any
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 2de3511459..e2955bc648 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -267,7 +267,7 @@ history, so we also add `--ignore-unmatch`:
 git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD
 --------------------------------------------------------------------------
 
-Now, you will get the rewritten history saved in HEAD.
+Now, you will get the rewritten history saved in `HEAD`.
 
 To rewrite the repository to look as if `foodir/` had been its project
 root, and discard all other history:
diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt
index 9004861eae..86fb26dcea 100644
--- a/Documentation/git-fmt-merge-msg.txt
+++ b/Documentation/git-fmt-merge-msg.txt
@@ -65,8 +65,8 @@ $ git fetch origin master
 $ git fmt-merge-msg --log <$GIT_DIR/FETCH_HEAD
 ---------
 
-Print a log message describing a merge of the "master" branch from
-the "origin" remote.
+Print a log message describing a merge of the `master` branch from
+the `origin` remote.
 
 
 SEE ALSO
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index e035edf11d..4bde4f9d05 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -76,18 +76,18 @@ OPTIONS
 
 --merged[=<object>]::
 	Only list refs whose tips are reachable from the
-	specified commit (HEAD if not specified).
+	specified commit (`HEAD` if not specified).
 
 --no-merged[=<object>]::
 	Only list refs whose tips are not reachable from the
-	specified commit (HEAD if not specified).
+	specified commit (`HEAD` if not specified).
 
 --contains[=<object>]::
-	Only list refs which contain the specified commit (HEAD if not
+	Only list refs which contain the specified commit (`HEAD` if not
 	specified).
 
 --no-contains[=<object>]::
-	Only list refs which don't contain the specified commit (HEAD
+	Only list refs which don't contain the specified commit (`HEAD`
 	if not specified).
 
 --ignore-case::
@@ -169,7 +169,7 @@ push::
 	ref is configured.
 
 HEAD::
-	'*' if HEAD matches current ref (the checked out branch), ' '
+	'*' if `HEAD` matches current ref (the checked out branch), ' '
 	otherwise.
 
 color::
@@ -201,7 +201,7 @@ if::
 	everything after %(else) is printed. We ignore space when
 	evaluating the string before %(then), this is useful when we
 	use the %(HEAD) atom which prints either "*" or " " and we
-	want to apply the 'if' condition only on the 'HEAD' ref.
+	want to apply the 'if' condition only on the `HEAD` ref.
 	Append ":equals=<string>" or ":notequals=<string>" to compare
 	the value between the %(if:...) and %(then) atoms with the
 	given string.
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index ca500ba72c..fd7c6c705b 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -706,7 +706,7 @@ $ git format-patch -k --stdout R1..R2 | git am -3 -k
 ------------
 
 * Extract all commits which are in the current branch but not in the
-  origin branch:
+  `origin` branch:
 +
 ------------
 $ git format-patch origin
@@ -714,7 +714,7 @@ $ git format-patch origin
 +
 For each commit a separate file is created in the current directory.
 
-* Extract all commits that lead to 'origin' since the inception of the
+* Extract all commits that lead to `origin` since the inception of the
   project:
 +
 ------------
diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt
index 5dd4d2b63a..7ba8ea2383 100644
--- a/Documentation/git-http-push.txt
+++ b/Documentation/git-http-push.txt
@@ -44,12 +44,12 @@ OPTIONS
 -d::
 -D::
 	Remove <ref> from remote repository.  The specified branch
-	cannot be the remote HEAD.  If `-d` is specified the following
+	cannot be the remote `HEAD`.  If `-d` is specified the following
 	other conditions must also be met:
 
-	- Remote HEAD must resolve to an object that exists locally
+	- Remote `HEAD` must resolve to an object that exists locally
 	- Specified branch resolves to an object that exists locally
-	- Specified branch is an ancestor of the remote HEAD
+	- Specified branch is an ancestor of the remote `HEAD`
 
 <ref>...::
 	The remote refs to update.
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 1bbf865a1b..b306dced1c 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -152,13 +152,13 @@ EXAMPLES
 `git log --branches --not --remotes=origin`::
 
 	Shows all commits that are in any of local branches but not in
-	any of remote-tracking branches for 'origin' (what you have that
-	origin doesn't).
+	any of remote-tracking branches for `origin` (what you have that
+	`origin` doesn't).
 
 `git log master --not --remotes=*/master`::
 
-	Shows all commits that are in local master but not in any remote
-	repository master branches.
+	Shows all commits that are in local `master` but not in any remote
+	repository `master` branches.
 
 `git log -p -m --first-parent`::
 
diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
index 4cb4e2fd5d..af005ece9a 100644
--- a/Documentation/git-ls-remote.txt
+++ b/Documentation/git-ls-remote.txt
@@ -59,7 +59,7 @@ OPTIONS
 --symref::
 	In addition to the object pointed by it, show the underlying
 	ref pointed by it when showing a symbolic ref.  Currently,
-	upload-pack only shows the symref HEAD, so it will be the only
+	upload-pack only shows the symref `HEAD`, so it will be the only
 	one shown by ls-remote.
 
 --sort=<key>::
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 3819fadac1..58fd091d73 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -146,7 +146,7 @@ To avoid recording unrelated changes in the merge commit,
 'git pull' and 'git merge' will also abort if there are any changes
 registered in the index relative to the `HEAD` commit.  (Special
 narrow exceptions to this rule may exist depending on which merge
-strategy is in use, but generally, the index must match HEAD.)
+strategy is in use, but generally, the index must match `HEAD`.)
 
 If all named commits are already ancestors of `HEAD`, 'git merge'
 will exit early with the message "Already up to date."
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index b0a5ab9a72..ef04e3a8ff 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -60,7 +60,7 @@ list::
 	This is the default subcommand if no subcommand is given.
 
 add::
-	Add notes for a given object (defaults to HEAD). Abort if the
+	Add notes for a given object (defaults to `HEAD`). Abort if the
 	object already has notes (use `-f` to overwrite existing notes).
 	However, if you're using `add` interactively (using an editor
 	to supply the notes contents), then - instead of aborting -
@@ -69,7 +69,7 @@ add::
 
 copy::
 	Copy the notes for the first object onto the second object (defaults to
-	HEAD). Abort if the second object already has notes, or if the first
+	`HEAD`). Abort if the second object already has notes, or if the first
 	object has none (use -f to overwrite existing notes to the
 	second object). This subcommand is equivalent to:
 	`git notes add [-f] -C $(git notes list <from-object>) <to-object>`
@@ -85,14 +85,14 @@ corresponding <to-object>.  (The optional `<rest>` is ignored so that
 the command can read the input given to the `post-rewrite` hook.)
 
 append::
-	Append to the notes of an existing object (defaults to HEAD).
+	Append to the notes of an existing object (defaults to `HEAD`).
 	Creates a new notes object if needed.
 
 edit::
-	Edit the notes for a given object (defaults to HEAD).
+	Edit the notes for a given object (defaults to `HEAD`).
 
 show::
-	Show the notes for a given object (defaults to HEAD).
+	Show the notes for a given object (defaults to `HEAD`).
 
 merge::
 	Merge the given notes ref into the current notes ref.
@@ -110,7 +110,7 @@ When done, the user can either finalize the merge with
 'git notes merge --abort'.
 
 remove::
-	Remove the notes for given objects (defaults to HEAD). When
+	Remove the notes for given objects (defaults to `HEAD`). When
 	giving zero or one object from the command line, this is
 	equivalent to specifying an empty note message to
 	the `edit` subcommand.
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index d9d29a5efa..ec23ab7d96 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -76,7 +76,7 @@ This:
 2. Imports the full contents of the head revision from the given p4
    depot path into a single commit in the Git branch 'refs/remotes/p4/master'.
 +
-3. Creates a local branch, 'master' from this remote and checks it out.
+3. Creates a local branch, `master` from this remote and checks it out.
 
 To reproduce the entire p4 history in Git, use the '@all' modifier on
 the depot path:
@@ -176,7 +176,7 @@ Unshelve
 Unshelving will take a shelved P4 changelist, and produce the equivalent git commit
 in the branch refs/remotes/p4-unshelved/<changelist>.
 
-The git commit is created relative to the current origin revision (HEAD by default).
+The git commit is created relative to the current origin revision (`HEAD` by default).
 A parent commit is created based on the origin, and then the unshelve commit is
 created based on that.
 
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index edecf393d3..d9a5507195 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -211,7 +211,7 @@ $ git pull
 $ git pull origin
 ------------------------------------------------
 +
-Normally the branch merged in is the HEAD of the remote repository,
+Normally the branch merged in is the `HEAD` of the remote repository,
 but the choice is determined by the branch.<name>.remote and
 branch.<name>.merge options; see linkgit:git-config[1] for details.
 
@@ -221,7 +221,7 @@ branch.<name>.merge options; see linkgit:git-config[1] for details.
 $ git pull origin next
 ------------------------------------------------
 +
-This leaves a copy of `next` temporarily in FETCH_HEAD, and
+This leaves a copy of `next` temporarily in `FETCH_HEAD`, and
 updates the remote-tracking branch `origin/next`.
 The same can be done by invoking fetch and merge:
 +
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index fc91d41ce0..91dcaa108c 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -667,9 +667,9 @@ made on `satellite`.
 	(e.g. `refs/heads/experimental`), and delete it.
 
 `git push origin +dev:master`::
-	Update the origin repository's master branch with the dev branch,
+	Update the `origin` repository's `master` branch with the `dev` branch,
 	allowing non-fast-forward updates.  *This can leave unreferenced
-	commits dangling in the origin repository.*  Consider the
+	commits dangling in the `origin` repository.*  Consider the
 	following situation, where a fast-forward is not possible:
 +
 ----
@@ -678,7 +678,7 @@ made on `satellite`.
 		      X---Y---Z  dev
 ----
 +
-The above command would change the origin repository to
+The above command would change the `origin` repository to
 +
 ----
 		      A---B  (unnamed branch)
@@ -688,7 +688,7 @@ The above command would change the origin repository to
 +
 Commits A and B would no longer belong to a branch with a symbolic name,
 and so would be unreachable.  As such, these commits would be removed by
-a `git gc` command on the origin repository.
+a `git gc` command on the `origin` repository.
 
 include::transfer-data-leaks.txt[]
 
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 3f53688170..d22d3855d1 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -118,7 +118,7 @@ OPTIONS
 --[no-]recurse-submodules::
 	Using `--recurse-submodules` will update the content of all active
 	submodules according to the commit recorded in the superproject by
-	calling read-tree recursively, also setting the submodules' HEAD to be
+	calling read-tree recursively, also setting the submodules' `HEAD` to be
 	detached at that commit.
 
 --no-sparse-checkout::
@@ -356,7 +356,7 @@ $ git fetch git://.... linus
 $ LT=`git rev-parse FETCH_HEAD`
 ----------------
 
-Your work tree is still based on your HEAD ($JC), but you have
+Your work tree is still based on your `HEAD` ($JC), but you have
 some edits since.  Three-way merge makes sure that you have not
 added or modified index entries since $JC, and if you haven't,
 then does the right thing.  So with the following sequence:
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index f063d54623..bd9f15ea26 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -35,13 +35,13 @@ description on `--fork-point` below); or by `git log HEAD`, if the
 
 The current branch is reset to <upstream>, or <newbase> if the
 `--onto` option was supplied.  This has the exact same effect as
-`git reset --hard <upstream>` (or <newbase>).  ORIG_HEAD is set
+`git reset --hard <upstream>` (or <newbase>).  `ORIG_HEAD` is set
 to point at the tip of the branch before the reset.
 
 The commits that were previously saved into the temporary area are
 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
+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
@@ -51,7 +51,7 @@ that caused the merge failure with `git rebase --skip`.  To check out the
 original <branch> and remove the .git/rebase-apply working files, use the
 command `git rebase --abort` instead.
 
-Assume the following history exists and the current branch is "topic":
+Assume the following history exists and the current branch is `topic`:
 
 ------------
           A---B---C topic
@@ -101,9 +101,9 @@ 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`.
 
-First let's assume your 'topic' is based on branch 'next'.
-For example, a feature developed in 'topic' depends on some
-functionality which is found in 'next'.
+First let's assume your `topic` is based on branch `next`.
+For example, a feature developed in `topic` depends on some
+functionality which is found in `next'.
 
 ------------
     o---o---o---o---o  master
@@ -113,9 +113,9 @@ functionality which is found in 'next'.
                             o---o---o  topic
 ------------
 
-We want to make 'topic' forked from branch 'master'; for example,
-because the functionality on which 'topic' depends was merged into the
-more stable 'master' branch. We want our tree to look like this:
+We want to make `topic` forked from branch `master`; for example,
+because the functionality on which `topic` depends was merged into the
+more stable `master` branch. We want our tree to look like this:
 
 ------------
     o---o---o---o---o  master
@@ -216,7 +216,7 @@ OPTIONS
 +
 As a special case, you may use "A\...B" as a shortcut for the
 merge base of A and B if there is exactly one merge base. You can
-leave out at most one of A and B, in which case it defaults to HEAD.
+leave out at most one of A and B, in which case it defaults to `HEAD`.
 
 --keep-base::
 	Set the starting point at which to create the new commits to the
@@ -242,20 +242,20 @@ See also INCOMPATIBLE OPTIONS below.
 	upstream for the current branch.
 
 <branch>::
-	Working branch; defaults to HEAD.
+	Working branch; defaults to `HEAD`.
 
 --continue::
 	Restart the rebasing process after having resolved a merge conflict.
 
 --abort::
-	Abort the rebase operation and reset HEAD to the original
+	Abort the rebase operation and reset `HEAD` to the original
 	branch. If <branch> was provided when the rebase operation was
-	started, then HEAD will be reset to <branch>. Otherwise HEAD
+	started, then `HEAD` will be reset to <branch>. Otherwise `HEAD`
 	will be reset to where it was when the rebase operation was
 	started.
 
 --quit::
-	Abort the rebase operation but HEAD is not reset back to the
+	Abort the rebase operation but `HEAD` is not reset back to the
 	original branch. The index and working tree are also left
 	unchanged as a result. If a temporary stash entry was created
 	using `--autostash`, it will be saved to the stash list.
@@ -905,7 +905,7 @@ when a command fails due to merge errors. When you are done editing
 and/or resolving conflicts you can continue with `git rebase --continue`.
 
 For example, if you want to reorder the last 5 commits, such that what
-was HEAD~4 becomes the new HEAD. To achieve that, you would call
+was `HEAD~4` becomes the new `HEAD`. To achieve that, you would call
 'git rebase' like this:
 
 ----------------------
@@ -925,8 +925,8 @@ like this:
 ---o---O---P---Q
 ------------------
 
-Suppose you want to rebase the side branch starting at "A" to "Q". Make
-sure that the current HEAD is "B", and call
+Suppose you want to rebase the side branch starting at `A` to `Q`. Make
+sure that the current `HEAD` is `B`, and call
 
 -----------------------------
 $ git rebase -i -r --onto Q O
@@ -990,7 +990,7 @@ add other commits.  This can be used to split a commit into two:
 - Mark the commit you want to split with the action "edit".
 
 - 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.
+  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
@@ -1020,8 +1020,8 @@ from the downstream's point of view.  The real fix, however, would be
 to avoid rebasing the upstream in the first place.
 
 To illustrate, suppose you are in a situation where someone develops a
-'subsystem' branch, and you are working on a 'topic' that is dependent
-on this 'subsystem'.  You might end up with a history like the
+`subsystem` branch, and you are working on a `topic` that is dependent
+on this `subsystem`.  You might end up with a history like the
 following:
 
 ------------
@@ -1032,7 +1032,7 @@ following:
 			    *---*---*  topic
 ------------
 
-If 'subsystem' is rebased against 'master', the following happens:
+If `subsystem` is rebased against `master`, the following happens:
 
 ------------
     o---o---o---o---o---o---o---o  master
@@ -1042,8 +1042,8 @@ If 'subsystem' is rebased against 'master', the following happens:
 			    *---*---*  topic
 ------------
 
-If you now continue development as usual, and eventually merge 'topic'
-to 'subsystem', the commits from 'subsystem' will remain duplicated forever:
+If you now continue development as usual, and eventually merge `topic`
+to `subsystem`, the commits from `subsystem` will remain duplicated forever:
 
 ------------
     o---o---o---o---o---o---o---o  master
@@ -1055,20 +1055,20 @@ to 'subsystem', the commits from 'subsystem' will remain duplicated forever:
 
 Such duplicates are generally frowned upon because they clutter up
 history, making it harder to follow.  To clean things up, you need to
-transplant the commits on 'topic' to the new 'subsystem' tip, i.e.,
-rebase 'topic'.  This becomes a ripple effect: anyone downstream from
-'topic' is forced to rebase too, and so on!
+transplant the commits on `topic` to the new `subsystem` tip, i.e.,
+rebase `topic`.  This becomes a ripple effect: anyone downstream from
+`topic` is forced to rebase too, and so on!
 
 There are two kinds of fixes, discussed in the following subsections:
 
 Easy case: The changes are literally the same.::
 
-	This happens if the 'subsystem' rebase was a simple rebase and
+	This happens if the `subsystem` rebase was a simple rebase and
 	had no conflicts.
 
 Hard case: The changes are not the same.::
 
-	This happens if the 'subsystem' rebase had conflicts, or used
+	This happens if the `subsystem` rebase had conflicts, or used
 	`--interactive` to omit, edit, squash, or fixup commits; or
 	if the upstream used one of `commit --amend`, `reset`, or
 	a full history rewriting command like
@@ -1079,13 +1079,13 @@ The easy case
 ~~~~~~~~~~~~~
 
 Only works if the changes (patch IDs based on the diff contents) on
-'subsystem' are literally the same before and after the rebase
-'subsystem' did.
+`subsystem` are literally the same before and after the rebase
+`subsystem` did.
 
 In that case, the fix is easy because 'git rebase' knows to skip
 changes that are already present in the new upstream (unless
 `--reapply-cherry-picks` is given). So if you say
-(assuming you're on 'topic')
+(assuming you're on `topic`)
 ------------
     $ git rebase subsystem
 ------------
@@ -1102,7 +1102,7 @@ you will end up with the fixed history
 The hard case
 ~~~~~~~~~~~~~
 
-Things get more complicated if the 'subsystem' changes do not exactly
+Things get more complicated if the `subsystem` changes do not exactly
 correspond to the ones before the rebase.
 
 NOTE: While an "easy case recovery" sometimes appears to be successful
@@ -1110,26 +1110,26 @@ NOTE: While an "easy case recovery" sometimes appears to be successful
       example, a commit that was removed via `git rebase
       --interactive` will be **resurrected**!
 
-The idea is to manually tell 'git rebase' "where the old 'subsystem'
-ended and your 'topic' began", that is, what the old merge base
+The idea is to manually tell 'git rebase' "where the old `subsystem`
+ended and your `topic` began", that is, what the old merge base
 between them was.  You will have to find a way to name the last commit
-of the old 'subsystem', for example:
+of the old `subsystem`, for example:
 
-* With the 'subsystem' reflog: after 'git fetch', the old tip of
-  'subsystem' is at `subsystem@{1}`.  Subsequent fetches will
+* With the `subsystem` reflog: after 'git fetch', the old tip of
+  `subsystem` is at `subsystem@{1}`.  Subsequent fetches will
   increase the number.  (See linkgit:git-reflog[1].)
 
-* Relative to the tip of 'topic': knowing that your 'topic' has three
-  commits, the old tip of 'subsystem' must be `topic~3`.
+* Relative to the tip of `topic`: knowing that your `topic` has three
+  commits, the old tip of `subsystem` must be `topic~3`.
 
-You can then transplant the old `subsystem..topic` to the new tip by
-saying (for the reflog case, and assuming you are on 'topic' already):
+You can then transplant the old `subsystem`..`topic` to the new tip by
+saying (for the reflog case, and assuming you are on `topic` already):
 ------------
     $ git rebase --onto subsystem subsystem@{1}
 ------------
 
 The ripple effect of a "hard case" recovery is especially bad:
-'everyone' downstream from 'topic' will now have to perform a "hard
+'everyone' downstream from `topic` will now have to perform a "hard
 case" recovery too!
 
 REBASING MERGES
@@ -1193,7 +1193,7 @@ merge -C 6f5e4d report-a-bug # Merge 'report-a-bug'
 In contrast to a regular interactive rebase, there are `label`, `reset`
 and `merge` commands in addition to `pick` ones.
 
-The `label` command associates a label with the current HEAD when that
+The `label` command associates a label with the current `HEAD` when that
 command is executed. These labels are created as worktree-local refs
 (`refs/rewritten/<label>`) that will be deleted when the rebase
 finishes. That way, rebase operations in multiple worktrees linked to
@@ -1201,7 +1201,7 @@ the same repository do not interfere with one another. If the `label`
 command fails, it is rescheduled immediately, with a helpful message how
 to proceed.
 
-The `reset` command resets the HEAD, index and worktree to the specified
+The `reset` command resets the `HEAD`, index and worktree to the specified
 revision. It is similar to an `exec git reset --hard <label>`, but
 refuses to overwrite untracked files. If the `reset` command fails, it is
 rescheduled immediately, with a helpful message how to edit the todo list
@@ -1209,7 +1209,7 @@ rescheduled immediately, with a helpful message how to edit the todo list
 list manually and contains a typo).
 
 The `merge` command will merge the specified revision(s) into whatever
-is HEAD at that time. With `-C <original-commit>`, the commit message of
+is `HEAD` at that time. With `-C <original-commit>`, the commit message of
 the specified merge commit will be used. When the `-C` is changed to
 a lower-case `-c`, the message will be opened in an editor after a
 successful merge so that the user can edit the message.
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index ff487ff77d..cf1d7e0810 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -28,8 +28,8 @@ depending on the subcommand:
 Reference logs, or "reflogs", record when the tips of branches and
 other references were updated in the local repository. Reflogs are
 useful in various Git commands, to specify the old value of a
-reference. For example, `HEAD@{2}` means "where HEAD used to be two
-moves ago", `master@{one.week.ago}` means "where master used to point
+reference. For example, `HEAD@{2}` means "where `HEAD` used to be two
+moves ago", `master@{one.week.ago}` means "where `master` used to point
 to one week ago in this local repository", and so on. See
 linkgit:gitrevisions[7] for more details.
 
diff --git a/Documentation/git-request-pull.txt b/Documentation/git-request-pull.txt
index 4d4392d0f8..f58164aee1 100644
--- a/Documentation/git-request-pull.txt
+++ b/Documentation/git-request-pull.txt
@@ -37,7 +37,7 @@ OPTIONS
 	The repository URL to be pulled from.
 
 <end>::
-	Commit to end at (defaults to HEAD).  This names the commit
+	Commit to end at (defaults to `HEAD`).  This names the commit
 	at the tip of the history you are asking to be pulled.
 +
 When the repository named by `<url>` has the commit at a tip of a
diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
index 4cfc883378..c5c6be5202 100644
--- a/Documentation/git-rerere.txt
+++ b/Documentation/git-rerere.txt
@@ -76,10 +76,10 @@ variables respectively.
 DISCUSSION
 ----------
 
-When your topic branch modifies an overlapping area that your
-master branch (or upstream) touched since your topic branch
-forked from it, you may want to test it with the latest master,
-even before your topic branch is ready to be pushed upstream:
+When your `topic` branch modifies an overlapping area that your
+`master` branch (or upstream) touched since your `topic` branch
+forked from it, you may want to test it with the latest `master`,
+even before your `topic` branch is ready to be pushed upstream:
 
 ------------
               o---*---o topic
@@ -87,8 +87,8 @@ even before your topic branch is ready to be pushed upstream:
     o---o---o---*---o---o master
 ------------
 
-For such a test, you need to merge master and topic somehow.
-One way to do it is to pull master into the topic branch:
+For such a test, you need to merge `master` and `topic` somehow.
+One way to do it is to pull `master` into the `topic` branch:
 
 ------------
 	$ git switch topic
@@ -106,9 +106,9 @@ work-in-progress still works with what is in the latest master.
 
 After this test merge, there are two ways to continue your work
 on the topic.  The easiest is to build on top of the test merge
-commit `+`, and when your work in the topic branch is finally
-ready, pull the topic branch into master, and/or ask the
-upstream to pull from you.  By that time, however, the master or
+commit `+`, and when your work in the `topic` branch is finally
+ready, pull the `topic` branch into `master`, and/or ask the
+upstream to pull from you.  By that time, however, the `master` or
 the upstream might have been advanced since the test merge `+`,
 in which case the final commit graph would look like this:
 
@@ -124,14 +124,14 @@ in which case the final commit graph would look like this:
     o---o---o---*---o---o---o---o---+ master
 ------------
 
-When your topic branch is long-lived, however, your topic branch
-would end up having many such "Merge from master" commits on it,
+When your `topic` branch is long-lived, however, your `topic` branch
+would end up having many such "Merge from `master`" commits on it,
 which would unnecessarily clutter the development history.
 Readers of the Linux kernel mailing list may remember that Linus
 complained about such too frequent test merges when a subsystem
 maintainer asked to pull from a branch full of "useless merges".
 
-As an alternative, to keep the topic branch clean of test
+As an alternative, to keep the `topic` branch clean of test
 merges, you could blow away the test merge, and keep building on
 top of the tip before the test merge:
 
@@ -148,8 +148,8 @@ top of the tip before the test merge:
     o---o---o---*---o---o---o---o---+ master
 ------------
 
-This would leave only one merge commit when your topic branch is
-finally ready and merged into the master branch.  This merge
+This would leave only one merge commit when your `topic` branch is
+finally ready and merged into the `master` branch.  This merge
 would require you to resolve the conflict, introduced by the
 commits marked with `*`.  However, this conflict is often the
 same conflict you resolved when you created the test merge you
@@ -163,7 +163,7 @@ usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in
 them.  Later, after you are done resolving the conflicts,
 running 'git rerere' again will record the resolved state of these
 files.  Suppose you did this when you created the test merge of
-master into the topic branch.
+`master` into the `topic` branch.
 
 Next time, after seeing the same conflicted automerge,
 running 'git rerere' will perform a three-way merge between the
@@ -185,12 +185,12 @@ the rerere.enabled config variable).
 
 In our example, when you do the test merge, the manual
 resolution is recorded, and it will be reused when you do the
-actual merge later with the updated master and topic branch, as long
+actual merge later with the updated `master` and `topic` branch, as long
 as the recorded resolution is still applicable.
 
 The information 'git rerere' records is also used when running
 'git rebase'.  After blowing away the test merge and continuing
-development on the topic branch:
+development on the `topic` branch:
 
 ------------
               o---*---o-------o---o topic
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index e9e816a986..4a55d1f1ac 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -3,7 +3,7 @@ git-reset(1)
 
 NAME
 ----
-git-reset - Reset current HEAD to the specified state
+git-reset - Reset current `HEAD` to the specified state
 
 SYNOPSIS
 --------
@@ -92,7 +92,7 @@ but carries forward unmerged index entries.
 	When the working tree is updated, using `--recurse-submodules` will
 	also recursively reset the working tree of all active submodules
 	according to the commit recorded in the superproject, also setting
-	the submodules' HEAD to be detached at that commit.
+	the submodules' `HEAD` to be detached at that commit.
 --
 
 See "Reset, restore and revert" in linkgit:git[1] for the differences
@@ -187,7 +187,7 @@ $ git switch topic/wip          <3>
     to be in the `master` branch.  You want to continue polishing
     them in a topic branch, so create `topic/wip` branch off of the
     current `HEAD`.
-<2> Rewind the master branch to get rid of those three commits.
+<2> Rewind the `master` branch to get rid of those three commits.
 <3> Switch to `topic/wip` branch and keep working.
 
 Undo commits permanently::
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 4b1af8c5a6..7c3c0e0007 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -155,7 +155,7 @@ for another option.
 	This is similar to `--symbolic`, but it omits input that
 	are not refs (i.e. branch or tag names; or more
 	explicitly disambiguating "heads/master" form, when you
-	want to name the "master" branch when there is an
+	want to name the `master` branch when there is an
 	unfortunately named tag "master"), and show them as full
 	refnames (e.g. "refs/heads/master").
 
@@ -475,7 +475,7 @@ This will error out if $REV is empty or not a valid revision.
 $ git rev-parse --default master --verify --end-of-options $REV
 ------------
 +
-but if $REV is empty, the commit object name from master will be printed.
+but if $REV is empty, the commit object name from `master` will be printed.
 
 GIT
 ---
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index bb92a4a451..a232db1d98 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -17,7 +17,7 @@ DESCRIPTION
 Given one or more existing commits, revert the changes that the
 related patches introduce, and record some new commits that record
 them.  This requires your working tree to be clean (no modifications
-from the HEAD commit).
+from the `HEAD` commit).
 
 Note: 'git revert' is used to record some new commits to reverse the
 effect of some earlier commits (often only a faulty one).  If you want to
@@ -82,7 +82,7 @@ more details.
 	to revert the named commits to your working tree
 	and the index, but does not make the commits.  In addition,
 	when this option is used, your index does not have to match
-	the HEAD commit.  The revert is done against the
+	the `HEAD` commit.  The revert is done against the
 	beginning state of your index.
 +
 This is useful when reverting more than one commits'
@@ -125,13 +125,13 @@ EXAMPLES
 --------
 `git revert HEAD~3`::
 
-	Revert the changes specified by the fourth last commit in HEAD
+	Revert the changes specified by the fourth last commit in `HEAD`
 	and create a new commit with the reverted changes.
 
 `git revert -n master~5..master~2`::
 
 	Revert the changes done by commits from the fifth last commit
-	in master (included) to the third last commit in master
+	in `master` (included) to the third last commit in `master`
 	(included), but do not create any commit with the reverted
 	changes. The revert only modifies the working tree and the
 	index.
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index e7ff1b5fbd..ea1f349a87 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -153,7 +153,7 @@ the submodule's history. If it exists the submodule.<name> section
 in the linkgit:gitmodules[5] file will also be removed and that file
 will be staged (unless `--cached` or `-n` are used).
 
-A submodule is considered up to date when the HEAD is the same as
+A submodule is considered up to date when the `HEAD` is the same as
 recorded in the index, no tracked files are modified and no untracked
 files that aren't ignored are present in the submodules work tree.
 Ignored files are deemed expendable and won't stop a submodule's work
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index 8c739adc70..9d7ba22603 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -35,7 +35,7 @@ OPTIONS
 
 --head::
 
-	Show the HEAD reference, even if it would normally be filtered out.
+	Show the `HEAD` reference, even if it would normally be filtered out.
 
 --heads::
 --tags::
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index 2b1bc7288d..b7a6f9b544 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -35,7 +35,7 @@ This manual page describes only the most frequently used options.
 OPTIONS
 -------
 <object>...::
-	The names of objects to show (defaults to 'HEAD').
+	The names of objects to show (defaults to `HEAD`).
 	For a more complete list of ways to spell object names, see
 	"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
 
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index a8c8c32f1e..a2b69ae00f 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -50,7 +50,7 @@ COMMANDS
 push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [-m|--message <message>] [--pathspec-from-file=<file> [--pathspec-file-nul]] [--] [<pathspec>...]::
 
 	Save your local modifications to a new 'stash entry' and roll them
-	back to HEAD (in the working tree and in the index).
+	back to `HEAD` (in the working tree and in the index).
 	The <message> part is optional and gives
 	the description along with the stashed state.
 +
@@ -121,7 +121,7 @@ branch <branchname> [<stash>]::
 +
 This is useful if the branch on which you ran `git stash push` has
 changed enough that `git stash apply` fails due to conflicts. Since
-the stash entry is applied on top of the commit that was HEAD at the
+the stash entry is applied on top of the commit that was `HEAD` at the
 time `git stash` was run, it restores the originally stashed state
 with no conflicts.
 
@@ -192,7 +192,7 @@ All changes already added to the index are left intact.
 --patch::
 	This option is only valid for `push` and `save` commands.
 +
-Interactively select hunks from the diff between HEAD and the
+Interactively select hunks from the diff between `HEAD` and the
 working tree to be stashed.  The stash entry is constructed such
 that its index state is the same as the index state of your
 repository, and its worktree contains only the changes you selected
@@ -237,7 +237,7 @@ Separates pathspec from options for disambiguation purposes.
 +
 The new stash entry records the modified states only for the files
 that match the pathspec.  The index entries and working tree files
-are then rolled back to the state in HEAD only for these files,
+are then rolled back to the state in `HEAD` only for these files,
 too, leaving files that do not match the pathspec intact.
 +
 For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 2fa3bc58f7..4b1951c5ce 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -14,7 +14,7 @@ SYNOPSIS
 DESCRIPTION
 -----------
 Displays paths that have differences between the index file and the
-current HEAD commit, paths that have differences between the working
+current `HEAD` commit, paths that have differences between the working
 tree and the index file, and paths in the working tree that are not
 tracked by Git (and are not ignored by linkgit:gitignore[5]). The first
 are what you _would_ commit by running `git commit`; the second and
@@ -88,7 +88,7 @@ configuration variable documented in linkgit:git-config[1].
 	Ignore changes to submodules when looking for changes. <when> can be
 	either "none", "untracked", "dirty" or "all", which is the default.
 	Using "none" will consider the submodule modified when it either contains
-	untracked or modified files or its HEAD differs from the commit recorded
+	untracked or modified files or its `HEAD` differs from the commit recorded
 	in the superproject and can be used to override any settings of the
 	'ignore' option in linkgit:git-config[1] or linkgit:gitmodules[5]. When
 	"untracked" is used submodules are not considered dirty when they only
@@ -242,7 +242,7 @@ U           U    unmerged, both modified
 ....
 
 Submodules have more state and instead report
-		M    the submodule has a different HEAD than
+		M    the submodule has a different `HEAD` than
 		     recorded in the index
 		m    the submodule has modified content
 		?    the submodule has untracked files
@@ -341,10 +341,10 @@ Field       Meaning
 	    <c> is "C" if the commit changed; otherwise ".".
 	    <m> is "M" if it has tracked changes; otherwise ".".
 	    <u> is "U" if there are untracked changes; otherwise ".".
-<mH>        The octal file mode in HEAD.
+<mH>        The octal file mode in `HEAD`.
 <mI>        The octal file mode in the index.
 <mW>        The octal file mode in the worktree.
-<hH>        The object name in HEAD.
+<hH>        The object name in `HEAD`.
 <hI>        The object name in the index.
 <X><score>  The rename or copy score (denoting the percentage
 	    of similarity between the source and target of the
@@ -354,7 +354,7 @@ Field       Meaning
 <sep>       When the `-z` option is used, the 2 pathnames are separated
 	    with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
 	    byte separates them.
-<origPath>  The pathname in the commit at HEAD or in the index.
+<origPath>  The pathname in the commit at `HEAD` or in the index.
 	    This is only present in a renamed/copied entry, and
 	    tells where the renamed/copied contents came from.
 --------------------------------------------------------
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 1bcde161ca..891c9e48e5 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -39,7 +39,7 @@ add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--dep
 	to the changeset to be committed next to the current
 	project: the current project is termed the "superproject".
 +
-<repository> is the URL of the new submodule's origin repository.
+<repository> is the URL of the new submodule's `origin` repository.
 This may be either an absolute URL, or (if it begins with ./
 or ../), the location relative to the superproject's default remote
 repository (Please note that to specify a repository 'foo.git'
@@ -50,7 +50,7 @@ of relative URLs in Git is identical to that of relative directories).
 +
 The default remote is the remote of the remote-tracking branch
 of the current branch. If no such remote-tracking branch exists or
-the HEAD is detached, "origin" is assumed to be the default remote.
+the `HEAD` is detached, `origin` is assumed to be the default remote.
 If the superproject doesn't have a default remote configured
 the superproject is its own authoritative upstream and the current
 working directory is used instead.
@@ -88,7 +88,7 @@ If `--recursive` is specified, this command will recurse into nested
 submodules, and show their status as well.
 +
 If you are only interested in changes of the currently initialized
-submodules with respect to the commit recorded in the index or the HEAD,
+submodules with respect to the commit recorded in the index or the `HEAD`,
 linkgit:git-status[1] and linkgit:git-diff[1] will provide that information
 too (and can also report changes to a submodule's work tree).
 
@@ -147,7 +147,7 @@ The 'update' procedures supported both from the command line as well as
 through the `submodule.<name>.update` configuration are:
 
 	checkout;; the commit recorded in the superproject will be
-	    checked out in the submodule on a detached HEAD.
+	    checked out in the submodule on a detached `HEAD`.
 +
 If `--force` is specified, the submodule will be checked out (using
 `git checkout --force`), even if the commit specified
@@ -183,7 +183,7 @@ set-branch (-d|--default) [--] <path>::
 	Sets the default remote tracking branch for the submodule. The
 	`--branch` option allows the remote branch to be specified. The
 	`--default` option removes the submodule.<name>.branch configuration
-	key, which causes the tracking branch to default to the remote 'HEAD'.
+	key, which causes the tracking branch to default to the remote `HEAD`.
 
 set-url [--] <path> <newurl>::
 	Sets the URL of the specified submodule to <newurl>. Then, it will
@@ -191,7 +191,7 @@ set-url [--] <path> <newurl>::
 	configuration.
 
 summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--] [<path>...]::
-	Show commit summary between the given commit (defaults to HEAD) and
+	Show commit summary between the given commit (defaults to `HEAD`) and
 	working tree/index. For a submodule in question, a series of commits
 	in the submodule between the given super project commit and the
 	index or working tree (switched by `--cached`) are shown. If the option
@@ -284,7 +284,7 @@ OPTIONS
 	`.gitmodules` for `update --remote`.  A special value of `.` is used to
 	indicate that the name of the branch in the submodule should be the
 	same name as the current branch in the current repository.  If the
-	option is not specified, it defaults to the remote 'HEAD'.
+	option is not specified, it defaults to the remote `HEAD`.
 
 -f::
 --force::
@@ -301,12 +301,12 @@ OPTIONS
 
 --cached::
 	This option is only valid for status and summary commands.  These
-	commands typically use the commit found in the submodule HEAD, but
+	commands typically use the commit found in the submodule `HEAD`, but
 	with this option, the commit stored in the index is used instead.
 
 --files::
 	This option is only valid for the summary command. This command
-	compares the commit in the index with that in the submodule HEAD
+	compares the commit in the index with that in the submodule `HEAD`
 	when this option is used.
 
 -n::
@@ -339,7 +339,7 @@ SHA-1.  If you don't want to fetch, you should use `submodule update
 --remote --no-fetch`.
 +
 Use this option to integrate changes from the upstream subproject with
-your submodule's current HEAD.  Alternatively, you can run `git pull`
+your submodule's current `HEAD`.  Alternatively, you can run `git pull`
 from the submodule, which is equivalent except for the remote branch
 name: `update --remote` uses the default upstream repository and
 `submodule.<name>.branch`, while `git pull` uses the submodule's
@@ -355,7 +355,7 @@ the submodule itself.
 
 --checkout::
 	This option is only valid for the update command.
-	Checkout the commit recorded in the superproject on a detached HEAD
+	Checkout the commit recorded in the superproject on a detached `HEAD`
 	in the submodule. This is the default behavior, the main use of
 	this option is to override `submodule.$name.update` when set to
 	a value other than `checkout`.
@@ -365,7 +365,7 @@ the submodule itself.
 --merge::
 	This option is only valid for the update command.
 	Merge the commit recorded in the superproject into the current branch
-	of the submodule. If this option is given, the submodule's HEAD will
+	of the submodule. If this option is given, the submodule's `HEAD` will
 	not be detached. If a merge failure prevents this process, you will
 	have to resolve the resulting conflicts within the submodule with the
 	usual conflict resolution tools.
@@ -375,7 +375,7 @@ the submodule itself.
 --rebase::
 	This option is only valid for the update command.
 	Rebase the current branch onto the commit recorded in the
-	superproject. If this option is given, the submodule's HEAD will not
+	superproject. If this option is given, the submodule's `HEAD` will not
 	be detached. If a merge failure prevents this process, you will have
 	to resolve these failures with linkgit:git-rebase[1].
 	If the key `submodule.$name.update` is set to `rebase`, this option is
@@ -432,7 +432,7 @@ options carefully.
 
 --[no-]single-branch::
 	This option is only valid for the update command.
-	Clone only one branch during update: HEAD or one specified by `--branch`.
+	Clone only one branch during update: `HEAD` or one specified by `--branch`.
 
 <path>...::
 	Paths to submodule(s). When specified this will restrict the command
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 3f55e9c419..f316b7dfc4 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -140,7 +140,7 @@ repository, either don't use this option or you should both use it in
 the same local time zone.
 
 --parent;;
-	Fetch only from the SVN parent of the current HEAD.
+	Fetch only from the SVN parent of the current `HEAD`.
 
 --ignore-refs=<regex>;;
 	Ignore refs for branches or tags matching the Perl regular
@@ -224,7 +224,7 @@ config key: svn-remote.<name>.include-paths
 	Default: ".gitignore"
 
 'rebase'::
-	This fetches revisions from the SVN parent of the current HEAD
+	This fetches revisions from the SVN parent of the current `HEAD`
 	and rebases the current (uncommitted to SVN) work against it.
 +
 This works similarly to `svn update` or 'git pull' except that
@@ -394,7 +394,7 @@ Any other arguments are passed directly to 'git log'
 	output of this mode is format-compatible with the output of
 	`svn blame' by default. Like the SVN blame command,
 	local uncommitted changes in the working tree are ignored;
-	the version of the file in the HEAD revision is annotated. Unknown
+	the version of the file in the `HEAD` revision is annotated. Unknown
 	arguments are passed directly to 'git blame'.
 +
 --git-format;;
@@ -558,7 +558,7 @@ git svn fetch
        r2---r3---A---B master
 ------------
 +
-Then fixup "master" with 'git rebase'.
+Then fixup `master` with 'git rebase'.
 Do NOT use 'git merge' or your history will not be compatible with a
 future 'dcommit'!
 +
@@ -954,7 +954,7 @@ HANDLING OF SVN BRANCHES
 If 'git svn' is configured to fetch branches (and `--follow-branches`
 is in effect), it sometimes creates multiple Git branches for one
 SVN branch, where the additional branches have names of the form
-'branchname@nnn' (with nnn an SVN revision number).  These additional
+`branchname@nnn` (with nnn an SVN revision number).  These additional
 branches are created if 'git svn' cannot find a parent commit for the
 first commit in an SVN branch, to connect the branch to the history of
 the other branches.
@@ -976,7 +976,7 @@ branch was copied from and create appropriate Git commits.  This is
 indicated by the message "Initializing parent: <branchname>".
 
 Additionally, it will create a special branch named
-'<branchname>@<SVN-Revision>', where <SVN-Revision> is the SVN revision
+`<branchname>@<SVN-Revision>`, where <SVN-Revision> is the SVN revision
 number the branch was copied from.  This branch will point to the newly
 created parent commit of the branch.  If in SVN the branch was deleted
 and later recreated from a different version, there will be multiple
@@ -988,12 +988,12 @@ single SVN revision.
 An example: in an SVN repository with a standard
 trunk/tags/branches layout, a directory trunk/sub is created in r.100.
 In r.200, trunk/sub is branched by copying it to branches/. 'git svn
-clone -s' will then create a branch 'sub'. It will also create new Git
+clone -s' will then create a branch `sub`. It will also create new Git
 commits for r.100 through r.199 and use these as the history of branch
-'sub'. Thus there will be two Git commits for each revision from r.100
+`sub`. Thus there will be two Git commits for each revision from r.100
 to r.199 (one containing trunk/, one containing trunk/sub/). Finally,
-it will create a branch 'sub@200' pointing to the new parent commit of
-branch 'sub' (i.e. the commit for r.200 and trunk/sub/).
+it will create a branch `sub@200` pointing to the new parent commit of
+branch `sub` (i.e. the commit for r.200 and trunk/sub/).
 
 CAVEATS
 -------
diff --git a/Documentation/git-switch.txt b/Documentation/git-switch.txt
index 5c438cd505..5737f25cf6 100644
--- a/Documentation/git-switch.txt
+++ b/Documentation/git-switch.txt
@@ -42,7 +42,7 @@ OPTIONS
 <start-point>::
 	The starting point for the new branch. Specifying a
 	`<start-point>` allows you to create a branch based on some
-	other point in history than where HEAD currently points. (Or,
+	other point in history than where `HEAD` currently points. (Or,
 	in the case of `--detach`, allows you to inspect and detach
 	from some other point.)
 +
@@ -99,7 +99,7 @@ the `checkout.defaultRemote` configuration variable, we'll use that
 one for the purposes of disambiguation, even if the `<branch>` isn't
 unique across all remotes. Set it to e.g. `checkout.defaultRemote=origin`
 to always checkout remote branches from there if `<branch>` is
-ambiguous but exists on the 'origin' remote. See also
+ambiguous but exists on the `origin` remote. See also
 `checkout.defaultRemote` in linkgit:git-config[1].
 +
 `--guess` is the default behavior. Use `--no-guess` to disable it.
@@ -193,7 +193,7 @@ name, the guessing is aborted.  You can explicitly give a name with
 EXAMPLES
 --------
 
-The following command switches to the "master" branch:
+The following command switches to the `master` branch:
 
 ------------
 $ git switch master
@@ -228,14 +228,14 @@ registered in your index file, so `git diff` would show you what
 changes you made since the tip of the new branch.
 
 To switch back to the previous branch before we switched to mytopic
-(i.e. "master" branch):
+(i.e. `master` branch):
 
 ------------
 $ git switch -
 ------------
 
 You can grow a new branch from any commit. For example, switch to
-"HEAD~3" and create branch "fixup":
+`HEAD~3` and create branch `fixup`:
 
 ------------
 $ git switch -c fixup HEAD~3
diff --git a/Documentation/git-symbolic-ref.txt b/Documentation/git-symbolic-ref.txt
index ef68ad2b71..2cbec2d033 100644
--- a/Documentation/git-symbolic-ref.txt
+++ b/Documentation/git-symbolic-ref.txt
@@ -39,7 +39,7 @@ OPTIONS
 -q::
 --quiet::
 	Do not issue an error message if the <name> is not a
-	symbolic ref but a detached HEAD; instead exit with
+	symbolic ref but a detached `HEAD`; instead exit with
 	non-zero status silently.
 
 --short::
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index b802972bb2..13a0d2abbb 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -209,7 +209,7 @@ This option is only applicable when listing tags without annotation lines.
 <commit>::
 <object>::
 	The object that the new tag will refer to, usually a commit.
-	Defaults to HEAD.
+	Defaults to `HEAD`.
 
 CONFIGURATION
 -------------
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index 3c3da97c29..be48daa825 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -20,7 +20,7 @@ Given three arguments, stores the <newvalue> in the <ref>,
 possibly dereferencing the symbolic refs, after verifying that
 the current value of the <ref> matches <oldvalue>.
 E.g. `git update-ref refs/heads/master <newvalue> <oldvalue>`
-updates the master branch head to <newvalue> only if its current
+updates the `master` branch head to <newvalue> only if its current
 value is <oldvalue>.  You can specify 40 "0" or an empty string
 as <oldvalue> to make sure that the ref you are creating does
 not exist.
@@ -151,7 +151,7 @@ LOGGING UPDATES
 ---------------
 If config parameter "core.logAllRefUpdates" is true and the ref is one
 under "refs/heads/", "refs/remotes/", "refs/notes/", or a pseudoref
-like HEAD or ORIG_HEAD; or the file "$GIT_DIR/logs/<ref>" exists then
+like `HEAD` or `ORIG_HEAD`; or the file "$GIT_DIR/logs/<ref>" exists then
 `git update-ref` will append a line to the log file
 "$GIT_DIR/logs/<ref>" (dereferencing all symbolic refs before creating
 the log name) describing the change in ref value.  Log lines are
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index f1bb1fa5f5..35bb1bb120 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -97,7 +97,7 @@ list::
 List details of each working tree.  The main working tree is listed first,
 followed by each of the linked working trees.  The output details include
 whether the working tree is bare, the revision currently checked out, the
-branch currently checked out (or "detached HEAD" if none), "locked" if
+branch currently checked out (or "detached `HEAD`" if none), "locked" if
 the worktree is locked, "prunable" if the worktree can be pruned by `prune`
 command.
 
diff --git a/Documentation/git.txt b/Documentation/git.txt
index fc49a4fd42..dcc52adff6 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -516,7 +516,7 @@ double-quotes and respecting backslash escapes. E.g., the value
 `GIT_COMMON_DIR`::
 	If this variable is set to a path, non-worktree files that are
 	normally in $GIT_DIR will be taken from this path
-	instead. Worktree-specific files such as HEAD or index are
+	instead. Worktree-specific files such as `HEAD` or index are
 	taken from $GIT_DIR. See linkgit:gitrepository-layout[5] and
 	linkgit:git-worktree[1] for
 	details. This variable has lower precedence than other path
@@ -914,7 +914,7 @@ standard output.
 `GIT_PRINT_SHA1_ELLIPSIS` (deprecated)::
 	If set to `yes`, print an ellipsis following an
 	(abbreviated) SHA-1 value.  This affects indications of
-	detached HEADs (linkgit:git-checkout[1]) and the raw
+	detached `HEAD`s (linkgit:git-checkout[1]) and the raw
 	diff output (linkgit:git-diff[1]).  Printing an
 	ellipsis in the cases mentioned is no longer considered
 	adequate and support for it is likely to be removed in the
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index 92e4ba6a2f..0fb18e3f35 100644
--- a/Documentation/gitcli.txt
+++ b/Documentation/gitcli.txt
@@ -29,7 +29,7 @@ arguments.  Here are the rules:
    E.g. `git diff -- HEAD` is, "I have a file called HEAD in my work
    tree.  Please show changes between the version I staged in the index
    and what I have in the work tree for that file", not "show difference
-   between the HEAD commit and the work tree as a whole".  You can say
+   between the `HEAD` commit and the work tree as a whole".  You can say
    `git diff HEAD --` to ask for the latter.
 
  * Without disambiguating `--`, Git makes a reasonable guess, but errors
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 633439702f..77573c813c 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -330,7 +330,7 @@ object name for the commit to its standard output.
 
 And this is where we create the `.git/refs/heads/master` file
 which is pointed at by `HEAD`. This file is supposed to contain
-the reference to the top-of-tree of the master branch, and since
+the reference to the top-of-tree of the `master` branch, and since
 that's exactly what 'git commit-tree' spits out, we can do this
 all with a sequence of simple shell commands:
 
@@ -402,7 +402,7 @@ In other words, 'git diff-index' normally compares a tree against the
 working tree, but when given the `--cached` flag, it is told to
 instead compare against just the index cache contents, and ignore the
 current working tree state entirely. Since we just wrote the index
-file to HEAD, doing `git diff-index --cached -p HEAD` should thus return
+file to `HEAD`, doing `git diff-index --cached -p HEAD` should thus return
 an empty set of differences, and that's exactly what it does.
 
 [NOTE]
@@ -446,7 +446,7 @@ flag or not, since now the index is coherent with the working tree.
 Now, since we've updated `hello` in the index, we can commit the new
 version. We could do it by writing the tree by hand again, and
 committing the tree (this time we'd have to use the `-p HEAD` flag to
-tell commit that the HEAD was the *parent* of the new commit, and that
+tell commit that the `HEAD` was the *parent* of the new commit, and that
 this wasn't an initial commit any more), but you've done that once
 already, so let's just use the helpful script this time:
 
@@ -822,7 +822,7 @@ commit log message from the command line.
 
 Now, to make it a bit more interesting, let's assume that somebody else
 does some work in the original branch, and simulate that by going back
-to the master branch, and editing the same file differently there:
+to the `master` branch, and editing the same file differently there:
 
 ------------
 $ git switch master
@@ -838,7 +838,7 @@ $ echo "Lots of fun" >>example
 $ git commit -m "Some fun." -i hello example
 ------------
 
-since the master branch is obviously in a much better mood.
+since the `master` branch is obviously in a much better mood.
 
 Now, you've got two branches, and you decide that you want to merge the
 work done. Before we do that, let's introduce a cool graphical tool that
@@ -933,21 +933,21 @@ shows an ordinary commit on the current branch, `-` is a merge commit), which
 means they are now part of the `master` branch. Only the "Some
 work" commit has the plus `+` character in the second column,
 because `mybranch` has not been merged to incorporate these
-commits from the master branch.  The string inside brackets
+commits from the `master` branch.  The string inside brackets
 before the commit log message is a short name you can use to
-name the commit.  In the above example, 'master' and 'mybranch'
-are branch heads.  'master^' is the first parent of 'master'
+name the commit.  In the above example, `master` and `mybranch`
+are branch heads.  `master^` is the first parent of `master`
 branch head.  Please see linkgit:gitrevisions[7] if you want to
 see more complex cases.
 
 [NOTE]
 Without the `--more=1` option, 'git show-branch' would not output the
 '[master^]' commit, as '[mybranch]' commit is a common ancestor of
-both 'master' and 'mybranch' tips.  Please see linkgit:git-show-branch[1]
+both `master` and `mybranch` tips.  Please see linkgit:git-show-branch[1]
 for details.
 
 [NOTE]
-If there were more commits on the 'master' branch after the merge, the
+If there were more commits on the `master` branch after the merge, the
 merge commit itself would not be shown by 'git show-branch' by
 default.  You would need to provide `--sparse` option to make the
 merge commit visible in this case.
@@ -1523,7 +1523,7 @@ like this:
    the initial cloning is stored in the remote.origin.url
    configuration variable.
 
-2. Do your work in your repository on 'master' branch.
+2. Do your work in your repository on `master` branch.
 
 3. Run `git fetch origin` from the public repository of your
    upstream every once in a while. This does only the first
@@ -1559,9 +1559,9 @@ using branches with Git.
 We have already seen how branches work previously,
 with "fun and work" example using two branches.  The idea is the
 same if there are more than two branches.  Let's say you started
-out from "master" head, and have some new code in the "master"
-branch, and two independent fixes in the "commit-fix" and
-"diff-fix" branches:
+out from `master` head, and have some new code in the `master`
+branch, and two independent fixes in the `commit-fix` and
+`diff-fix` branches:
 
 ------------
 $ git show-branch
@@ -1577,8 +1577,8 @@ $ git show-branch
 ------------
 
 Both fixes are tested well, and at this point, you want to merge
-in both of them.  You could merge in 'diff-fix' first and then
-'commit-fix' next, like this:
+in both of them.  You could merge in `diff-fix` first and then
+`commit-fix` next, like this:
 
 ------------
 $ git merge -m "Merge fix in diff-fix" diff-fix
@@ -1607,8 +1607,8 @@ first and the other next, when what you have are a set of truly
 independent changes (if the order mattered, then they are not
 independent by definition).  You could instead merge those two
 branches into the current branch at once.  First let's undo what
-we just did and start over.  We would want to get the master
-branch before these two merges by resetting it to 'master~2':
+we just did and start over.  We would want to get the `master`
+branch before these two merges by resetting it to `master~2`:
 
 ------------
 $ git reset --hard master~2
diff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt
index faba2ef088..03c9e5e8d5 100644
--- a/Documentation/giteveryday.txt
+++ b/Documentation/giteveryday.txt
@@ -104,8 +104,8 @@ modification will be caught if you do `git commit -a` later.
 <6> look at all your changes including the previous commit.
 <7> amend the previous commit, adding all your new changes,
 using your original message.
-<8> switch to the master branch.
-<9> merge a topic branch into your master branch.
+<8> switch to the `master` branch.
+<9> merge a topic branch into your `master` branch.
 <10> review commit logs; other forms to limit output can be
 combined and include `-10` (to show up to 10 commits),
 `--until=2005-12-10`, etc.
@@ -123,7 +123,7 @@ addition to the ones needed by a standalone developer.
   * linkgit:git-clone[1] from the upstream to prime your local
     repository.
 
-  * linkgit:git-pull[1] and linkgit:git-fetch[1] from "origin"
+  * linkgit:git-pull[1] and linkgit:git-fetch[1] from `origin`
     to keep up-to-date with the upstream.
 
   * linkgit:git-push[1] to shared repository, if you adopt CVS
@@ -160,9 +160,9 @@ $ git reset --hard ORIG_HEAD <10>
 $ git gc <11>
 ------------
 +
-<1> checkout a new branch `mine` from master.
+<1> checkout a new branch `mine` from `master`.
 <2> repeat as needed.
-<3> extract patches from your branch, relative to master,
+<3> extract patches from your branch, relative to `master`,
 <4> and email them.
 <5> return to `master`, ready to see what's new
 <6> `git pull` fetches from `origin` by default and merges into the
@@ -210,7 +210,7 @@ remote-tracking branches on the mothership machine.  You could use this
 as a back-up method. Likewise, you can pretend that mothership
 "fetched" from you (useful when access is one sided).
 <5> on mothership machine, merge the work done on the satellite
-machine into the master branch.
+machine into the `master` branch.
 
 Branch off of a specific tag.::
 +
@@ -305,7 +305,7 @@ master or exposed as a part of a stable branch.
 <8> and bundle topic branches still cooking.
 <9> backport a critical fix.
 <10> create a signed tag.
-<11> make sure master was not accidentally rewound beyond that
+<11> make sure `master` was not accidentally rewound beyond that
 already pushed out.
 <12> In the output from `git show-branch`, `master` should have
 everything `ko/master` has, and `next` should have
@@ -446,7 +446,7 @@ refs/tags/v[0-9]*	david
 <2> and make the shared repository writable by the group.
 <3> use update-hook example by Carl from Documentation/howto/
 for branch policy control.
-<4> alice and cindy can push into master, only bob can push into doc-update.
+<4> alice and cindy can push into `master`, only bob can push into `doc-update`.
 david is the release manager and is the only person who can
 create and push version tags.
 
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index b51959ff94..5e87987882 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -189,8 +189,8 @@ post-checkout
 
 This hook is invoked when a linkgit:git-checkout[1] or
 linkgit:git-switch[1] is run after having updated the
-worktree.  The hook is given three parameters: the ref of the previous HEAD,
-the ref of the new HEAD (which may or may not have changed), and a flag
+worktree.  The hook is given three parameters: the ref of the previous `HEAD`,
+the ref of the new `HEAD` (which may or may not have changed), and a flag
 indicating whether the checkout was a branch checkout (changing branches,
 flag=1) or a file checkout (retrieving a file from the index, flag=0).
 This hook cannot affect the outcome of `git switch` or `git checkout`,
@@ -199,11 +199,11 @@ these two commands.
 
 It is also run after linkgit:git-clone[1], unless the `--no-checkout` (`-n`) option is
 used. The first parameter given to the hook is the null-ref, the second the
-ref of the new HEAD and the flag is always 1. Likewise for `git worktree add`
+ref of the new `HEAD` and the flag is always 1. Likewise for `git worktree add`
 unless `--no-checkout` is used.
 
 This hook can be used to perform repository validity checks, auto-display
-differences from the previous HEAD if different, or set working dir metadata
+differences from the previous `HEAD` if different, or set working dir metadata
 properties.
 
 post-merge
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 6ceeae227c..29bd307bb9 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -64,7 +64,7 @@ linkgit:git-rev-list[1] for a complete list.
 --merge::
 
 	After an attempt to merge stops with conflicts, show the commits on
-	the history between two branches (i.e. the HEAD and the MERGE_HEAD)
+	the history between two branches (i.e. the `HEAD` and the `MERGE_HEAD`)
 	that modify the conflicted files and do not exist on all the heads
 	being merged.
 
diff --git a/Documentation/gitnamespaces.txt b/Documentation/gitnamespaces.txt
index b614969ad2..29bac9e1bf 100644
--- a/Documentation/gitnamespaces.txt
+++ b/Documentation/gitnamespaces.txt
@@ -16,7 +16,7 @@ DESCRIPTION
 -----------
 
 Git supports dividing the refs of a single repository into multiple
-namespaces, each of which has its own branches, tags, and HEAD.  Git can
+namespaces, each of which has its own branches, tags, and `HEAD`.  Git can
 expose each namespace as an independent repository to pull from and push
 to, while sharing the object store, and exposing all the refs to
 operations such as linkgit:git-gc[1].
diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt
index 6f1e269ae4..f5ac7ae7ca 100644
--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -322,9 +322,9 @@ Supported if the helper has the "fetch" capability.
 	(if there is only one reference to push, a single 'push' command
 	is followed by a blank line). For example, the following would
 	be two batches of 'push', the first asking the remote-helper
-	to push the local ref 'master' to the remote ref 'master' and
-	the local `HEAD` to the remote 'branch', and the second
-	asking to push ref 'foo' to ref 'bar' (forced update requested
+	to push the local ref `master` to the remote ref `master` and
+	the local `HEAD` to the remote `branch`, and the second
+	asking to push ref `foo` to ref `bar` (forced update requested
 	by the '+').
 +
 ------------
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index 1a2ef4c150..e174a28360 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -128,7 +128,7 @@ HEAD::
 	describing the currently active branch.  It does not mean
 	much if the repository is not associated with any working tree
 	(i.e. a 'bare' repository), but a valid Git repository
-	*must* have the HEAD file; some porcelains may use it to
+	*must* have the `HEAD` file; some porcelains may use it to
 	guess the designated "default" branch of the repository
 	(usually 'master').  It is legal if the named branch
 	'name' does not (yet) exist.  In some legacy setups, it is
@@ -137,7 +137,7 @@ HEAD::
 +
 HEAD can also record a specific commit directly, instead of
 being a symref to point at the current branch.  Such a state
-is often called 'detached HEAD.'  See linkgit:git-checkout[1]
+is often called 'detached `HEAD`.'  See linkgit:git-checkout[1]
 for details.
 
 config::
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index e1e09070ad..2b3cba8ae3 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -132,7 +132,7 @@ and the contents of these files is just the compressed data plus a
 header identifying their length and their type.  The type is either a
 blob, a tree, a commit, or a tag.
 
-The simplest commit to find is the HEAD commit, which we can find
+The simplest commit to find is the `HEAD` commit, which we can find
 from .git/HEAD:
 
 ------------------------------------------------
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index ff366cc752..089a89f776 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -182,7 +182,7 @@ Managing branches
 -----------------
 
 A single Git repository can maintain multiple branches of
-development.  To create a new branch named "experimental", use
+development.  To create a new branch named `experimental`, use
 
 ------------------------------------------------
 $ git branch experimental
@@ -201,8 +201,8 @@ you'll get a list of all existing branches:
 * master
 ------------------------------------------------
 
-The "experimental" branch is the one you just created, and the
-"master" branch is a default branch that was created for you
+The `experimental` branch is the one you just created, and the
+`master` branch is a default branch that was created for you
 automatically.  The asterisk marks the branch you are currently on;
 type
 
@@ -211,7 +211,7 @@ $ git switch experimental
 ------------------------------------------------
 
 to switch to the experimental branch.  Now edit a file, commit the
-change, and switch back to the master branch:
+change, and switch back to the `master` branch:
 
 ------------------------------------------------
 (edit file)
@@ -220,9 +220,9 @@ $ git switch master
 ------------------------------------------------
 
 Check that the change you made is no longer visible, since it was
-made on the experimental branch and you're back on the master branch.
+made on the experimental branch and you're back on the `master` branch.
 
-You can make a different change on the master branch:
+You can make a different change on the `master` branch:
 
 ------------------------------------------------
 (edit file)
@@ -230,7 +230,7 @@ $ git commit -a
 ------------------------------------------------
 
 at this point the two branches have diverged, with different changes
-made in each.  To merge the changes made in experimental into master, run
+made in each.  To merge the changes made in `experimental` into `master`, run
 
 ------------------------------------------------
 $ git merge experimental
@@ -310,7 +310,7 @@ alice$ cd /home/alice/project
 alice$ git pull /home/bob/myrepo master
 ------------------------------------------------
 
-This merges the changes from Bob's "master" branch into Alice's
+This merges the changes from Bob's `master` branch into Alice's
 current branch.  If Alice has made her own changes in the meantime,
 then she may need to manually fix any conflicts.
 
@@ -327,7 +327,7 @@ some way and pull again when this happens).
 
 Alice can peek at what Bob did without merging first, using the "fetch"
 command; this allows Alice to inspect what Bob did, using a special
-symbol "FETCH_HEAD", in order to determine if he has anything worth
+symbol `FETCH_HEAD`, in order to determine if he has anything worth
 pulling, like this:
 
 ------------------------------------------------
@@ -336,10 +336,10 @@ alice$ git log -p HEAD..FETCH_HEAD
 ------------------------------------------------
 
 This operation is safe even if Alice has uncommitted local changes.
-The range notation "HEAD..FETCH_HEAD" means "show everything that is reachable
-from the FETCH_HEAD but exclude anything that is reachable from HEAD".
-Alice already knows everything that leads to her current state (HEAD),
-and reviews what Bob has in his state (FETCH_HEAD) that she has not
+The range notation "`HEAD`..`FETCH_HEAD`" means "show everything that is reachable
+from the `FETCH_HEAD` but exclude anything that is reachable from `HEAD`".
+Alice already knows everything that leads to her current state (`HEAD`),
+and reviews what Bob has in his state (`FETCH_HEAD`) that she has not
 seen with this command.
 
 If Alice wants to visualize what Bob did since their histories forked
@@ -397,10 +397,10 @@ alice$ git log -p master..bob/master
 -------------------------------------
 
 shows a list of all the changes that Bob made since he branched from
-Alice's master branch.
+Alice's `master` branch.
 
 After examining those changes, Alice
-could merge the changes into her master branch:
+could merge the changes into her `master` branch:
 
 -------------------------------------
 alice$ git merge bob/master
@@ -436,8 +436,8 @@ bob$ git config --get remote.origin.url
 `git config -l`, and the linkgit:git-config[1] man page
 explains the meaning of each option.)
 
-Git also keeps a pristine copy of Alice's master branch under the
-name "origin/master":
+Git also keeps a pristine copy of Alice's `master` branch under the
+name `origin/master`:
 
 -------------------------------------
 bob$ git branch -r
@@ -570,22 +570,22 @@ $ git log v2.5.. Makefile       # commits since v2.5 which modify
 
 You can also give 'git log' a "range" of commits where the first is not
 necessarily an ancestor of the second; for example, if the tips of
-the branches "stable" and "master" diverged from a common
+the branches `stable` and `master` diverged from a common
 commit some time ago, then
 
 -------------------------------------
 $ git log stable..master
 -------------------------------------
 
-will list commits made in the master branch but not in the
-stable branch, while
+will list commits made in the `master` branch but not in the
+`stable` branch, while
 
 -------------------------------------
 $ git log master..stable
 -------------------------------------
 
-will show the list of commits made on the stable branch but not
-the master branch.
+will show the list of commits made on the `stable` branch but not
+the `master` branch.
 
 The 'git log' command has a weakness: it must present commits in a
 list.  When the history has lines of development that diverged and
diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt
index 3cc9b034c4..ee6e6a30fd 100644
--- a/Documentation/gitweb.txt
+++ b/Documentation/gitweb.txt
@@ -291,7 +291,7 @@ action::
 	is not set, and to 'summary' otherwise.
 
 revision::
-	Revision shown.  Defaults to HEAD.
+	Revision shown.  Defaults to `HEAD`.
 
 path::
 	The path within the <repository> that the action is performed on,
@@ -385,7 +385,7 @@ The 'shortlog' view is more compact; it shows one commit per line.
 
 history::
 	Shows history of the file or directory in a given repository path,
-	starting from given revision (defaults to HEAD, i.e. default branch).
+	starting from given revision (defaults to `HEAD`, i.e. default branch).
 +
 This view is similar to 'shortlog' view.
 
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 47cf97f9be..07344bf85a 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -75,25 +75,25 @@ As a given feature goes from experimental to stable, it also
 "graduates" between the corresponding branches of the software.
 `git.git` uses the following 'integration branches':
 
-* 'maint' tracks the commits that should go into the next "maintenance
+* `maint` tracks the commits that should go into the next "maintenance
   release", i.e., update of the last released stable version;
 
-* 'master' tracks the commits that should go into the next release;
+* `master` tracks the commits that should go into the next release;
 
-* 'next' is intended as a testing branch for topics being tested for
-  stability for master.
+* `next` is intended as a testing branch for topics being tested for
+  stability for `master`.
 
 There is a fourth official branch that is used slightly differently:
 
-* 'seen' (patches seen by the maintainer) is an integration branch for
+* `seen` (patches seen by the maintainer) is an integration branch for
   things that are not quite ready for inclusion yet (see "Integration
   Branches" below).
 
 Each of the four branches is usually a direct descendant of the one
 above it.
 
-Conceptually, the feature enters at an unstable branch (usually 'next'
-or 'seen'), and "graduates" to 'master' for the next release once it is
+Conceptually, the feature enters at an unstable branch (usually `next`
+or `seen`), and "graduates" to `master` for the next release once it is
 considered stable enough.
 
 
@@ -113,7 +113,7 @@ other.
 =====================================
 
 This gives a very controlled flow of fixes.  If you notice that you
-have applied a fix to e.g. 'master' that is also required in 'maint',
+have applied a fix to e.g. `master` that is also required in `maint`,
 you will need to cherry-pick it (using linkgit:git-cherry-pick[1])
 downwards.  This will happen a few times and is nothing to worry about
 unless you do it very frequently.
@@ -149,11 +149,11 @@ Many things can then be done very naturally:
   it.  If the topic has evolved further in the meantime, merge again.
   (Note that you do not necessarily have to merge it to the oldest
   integration branch first.  For example, you can first merge a bugfix
-  to 'next', give it some testing time, and merge to 'maint' when you
+  to `next`, give it some testing time, and merge to `maint` when you
   know it is stable.)
 
-* If you find you need new features from the branch 'other' to continue
-  working on your topic, merge 'other' to 'topic'.  (However, do not
+* If you find you need new features from the branch `other` to continue
+  working on your topic, merge `other` to `topic`.  (However, do not
   do this "just habitually", see below.)
 
 * If you find you forked off the wrong branch and want to move it
@@ -207,7 +207,7 @@ If you make it (very) clear that this branch is going to be deleted
 right after the testing, you can even publish this branch, for example
 to give the testers a chance to work with it, or other developers a
 chance to see if their in-progress work will be compatible.  `git.git`
-has such an official throw-away integration branch called 'seen'.
+has such an official throw-away integration branch called `seen`.
 
 
 Branch management for a release
@@ -217,27 +217,27 @@ Assuming you are using the merge approach discussed above, when you
 are releasing your project you will need to do some additional branch
 management work.
 
-A feature release is created from the 'master' branch, since 'master'
+A feature release is created from the `master` branch, since `master`
 tracks the commits that should go into the next feature release.
 
-The 'master' branch is supposed to be a superset of 'maint'. If this
-condition does not hold, then 'maint' contains some commits that
-are not included on 'master'. The fixes represented by those commits
+The `master` branch is supposed to be a superset of `maint`. If this
+condition does not hold, then `maint` contains some commits that
+are not included on `master`. The fixes represented by those commits
 will therefore not be included in your feature release.
 
-To verify that 'master' is indeed a superset of 'maint', use git log:
+To verify that `master` is indeed a superset of `maint`, use git log:
 
-.Verify 'master' is a superset of 'maint'
+.Verify `master` is a superset of `maint`
 [caption="Recipe: "]
 =====================================
 `git log master..maint`
 =====================================
 
 This command should not list any commits.  Otherwise, check out
-'master' and merge 'maint' into it.
+`master` and merge `maint` into it.
 
 Now you can proceed with the creation of the feature release. Apply a
-tag to the tip of 'master' indicating the release version:
+tag to the tip of `master` indicating the release version:
 
 .Release tagging
 [caption="Recipe: "]
@@ -251,9 +251,9 @@ others tracking your project. The push could also trigger a
 post-update hook to perform release-related items such as building
 release tarballs and preformatted documentation pages.
 
-Similarly, for a maintenance release, 'maint' is tracking the commits
+Similarly, for a maintenance release, `maint` is tracking the commits
 to be released. Therefore, in the steps above simply tag and push
-'maint' rather than 'master'.
+`maint` rather than `master`.
 
 
 Maintenance branch management after a feature release
@@ -275,10 +275,10 @@ where X.Y.Z is the current release).
 `git branch maint-X.Y.(Z-1) maint`
 =====================================
 
-The 'maint' branch should now be fast-forwarded to the newly released
+The `maint` branch should now be fast-forwarded to the newly released
 code so that maintenance fixes can be tracked for the current release:
 
-.Update maint to new release
+.Update `maint` to new release
 [caption="Recipe: "]
 =====================================
 * `git checkout maint`
@@ -286,7 +286,7 @@ code so that maintenance fixes can be tracked for the current release:
 =====================================
 
 If the merge fails because it is not a fast-forward, then it is
-possible some fixes on 'maint' were missed in the feature release.
+possible some fixes on `maint` were missed in the feature release.
 This will not happen if the content of the branches was verified as
 described in the previous section.
 
@@ -294,9 +294,9 @@ described in the previous section.
 Branch management for next and seen after a feature release
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-After a feature release, the integration branch 'next' may optionally be
-rewound and rebuilt from the tip of 'master' using the surviving
-topics on 'next':
+After a feature release, the integration branch `next` may optionally be
+rewound and rebuilt from the tip of `master` using the surviving
+topics on `next`:
 
 .Rewind and rebuild next
 [caption="Recipe: "]
@@ -307,20 +307,20 @@ topics on 'next':
 * ...
 =====================================
 
-The advantage of doing this is that the history of 'next' will be
-clean. For example, some topics merged into 'next' may have initially
+The advantage of doing this is that the history of `next` will be
+clean. For example, some topics merged into `next` may have initially
 looked promising, but were later found to be undesirable or premature.
-In such a case, the topic is reverted out of 'next' but the fact
+In such a case, the topic is reverted out of `next` but the fact
 remains in the history that it was once merged and reverted. By
-recreating 'next', you give another incarnation of such topics a clean
+recreating `next`, you give another incarnation of such topics a clean
 slate to retry, and a feature release is a good point in history to do
 so.
 
 If you do this, then you should make a public announcement indicating
-that 'next' was rewound and rebuilt.
+that `next` was rewound and rebuilt.
 
-The same rewind and rebuild process may be followed for 'seen'. A public
-announcement is not necessary since 'seen' is a throw-away branch, as
+The same rewind and rebuild process may be followed for `seen`. A public
+announcement is not necessary since `seen` is a throw-away branch, as
 described above.
 
 
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 67c7a50b96..88ee109fdf 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -113,16 +113,16 @@ to point at the new commit.
 [[def_detached_HEAD]]detached HEAD::
 	Normally the <<def_HEAD,HEAD>> stores the name of a
 	<<def_branch,branch>>, and commands that operate on the
-	history HEAD represents operate on the history leading to the
-	tip of the branch the HEAD points at.  However, Git also
+	history `HEAD` represents operate on the history leading to the
+	tip of the branch the `HEAD` points at.  However, Git also
 	allows you to <<def_checkout,check out>> an arbitrary
 	<<def_commit,commit>> that isn't necessarily the tip of any
-	particular branch.  The HEAD in such a state is called
+	particular branch.  The `HEAD` in such a state is called
 	"detached".
 +
 Note that commands that operate on the history of the current branch
 (e.g. `git commit` to build a new history on top of it) still work
-while the HEAD is detached. They update the HEAD to point at the tip
+while the `HEAD` is detached. They update the `HEAD` to point at the tip
 of the updated history without affecting any branch.  Commands that
 update or inquire information _about_ the current branch (e.g. `git
 branch --set-upstream-to` that sets what remote-tracking branch the
@@ -193,7 +193,7 @@ for a more flexible and robust system to do the same thing.
 [[def_HEAD]]HEAD::
 	The current <<def_branch,branch>>.  In more detail: Your <<def_working_tree,
 	working tree>> is normally derived from the state of the tree
-	referred to by HEAD.  HEAD is a reference to one of the
+	referred to by `HEAD`.  `HEAD` is a reference to one of the
 	<<def_head,heads>> in your repository, except when using a
 	<<def_detached_HEAD,detached HEAD>>, in which case it directly
 	references an arbitrary commit.
@@ -456,7 +456,7 @@ exclude;;
 	like refs for the purposes of rev-parse, but which are treated
 	specially by git.  Pseudorefs both have names that are all-caps,
 	and always start with a line consisting of a
-	<<def_SHA1,SHA-1>> followed by whitespace.  So, HEAD is not a
+	<<def_SHA1,SHA-1>> followed by whitespace.  So, `HEAD` is not a
 	pseudoref, because it is sometimes a symbolic ref.  They might
 	optionally contain some additional data.  `MERGE_HEAD` and
 	`CHERRY_PICK_HEAD` are examples.  Unlike
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 965cb32f9c..e6e9669f68 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -252,7 +252,7 @@ to list all commits on only one side of them is with
 `--left-right` (see the example below in the description of
 the `--left-right` option). However, it shows the commits that were
 cherry-picked from the other branch (for example, ``3rd on b'' may be
-cherry-picked from branch A). With this option, such pairs of commits are
+cherry-picked from branch `A`). With this option, such pairs of commits are
 excluded from the output.
 
 --left-only::
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index d9169c062e..33f30b62eb 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -23,8 +23,8 @@ characters and to avoid word splitting.
   followed by a dash and a number of commits, followed by a dash, a
   'g', and an abbreviated object name.
 
-'<refname>', e.g. 'master', 'heads/master', 'refs/heads/master'::
-  A symbolic ref name.  E.g. 'master' typically means the commit
+'<refname>', e.g. `master`, 'heads/master', 'refs/heads/master'::
+  A symbolic ref name.  E.g. `master` typically means the commit
   object referenced by 'refs/heads/master'.  If you
   happen to have both 'heads/master' and 'tags/master', you can
   explicitly say 'heads/master' to tell Git which one you mean.
@@ -65,7 +65,7 @@ some output processing may assume ref names in UTF-8.
 '@'::
   '@' alone is a shortcut for `HEAD`.
 
-'[<refname>]@{<date>}', e.g. 'master@\{yesterday\}', 'HEAD@{5 minutes ago}'::
+'[<refname>]@{<date>}', e.g. `master@{yesterday}`, `HEAD@{5 minutes ago}`::
   A ref followed by the suffix '@' with a date specification
   enclosed in a brace
   pair (e.g. '\{yesterday\}', '{1 month 2 weeks 3 days 1 hour 1
@@ -74,28 +74,28 @@ some output processing may assume ref names in UTF-8.
   used immediately following a ref name and the ref must have an
   existing log ('$GIT_DIR/logs/<ref>'). Note that this looks up the state
   of your *local* ref at a given time; e.g., what was in your local
-  'master' branch last week. If you want to look at commits made during
+  `master` branch last week. If you want to look at commits made during
   certain times, see `--since` and `--until`.
 
-'<refname>@{<n>}', e.g. 'master@\{1\}'::
+'<refname>@{<n>}', e.g. `master@{1}`::
   A ref followed by the suffix '@' with an ordinal specification
   enclosed in a brace pair (e.g. '\{1\}', '\{15\}') specifies
-  the n-th prior value of that ref.  For example 'master@\{1\}'
-  is the immediate prior value of 'master' while 'master@\{5\}'
-  is the 5th prior value of 'master'. This suffix may only be used
+  the n-th prior value of that ref.  For example `master@{1}`
+  is the immediate prior value of `master` while `master@{5}`
+  is the 5th prior value of `master`. This suffix may only be used
   immediately following a ref name and the ref must have an existing
   log ('$GIT_DIR/logs/<refname>').
 
 '@{<n>}', e.g. '@\{1\}'::
   You can use the '@' construct with an empty ref part to get at a
   reflog entry of the current branch. For example, if you are on
-  branch 'blabla' then '@\{1\}' means the same as 'blabla@\{1\}'.
+  branch `blabla` then `@{1}` means the same as `blabla@{1}`.
 
 '@{-<n>}', e.g. '@{-1}'::
   The construct '@{-<n>}' means the <n>th branch/commit checked out
   before the current one.
 
-'[<branchname>]@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
+'[<branchname>]@\{upstream\}', e.g. `master@{upstream}`, '@\{u\}'::
   The suffix '@\{upstream\}' to a branchname (short form '<branchname>@\{u\}')
   refers to the branch that the branch specified by branchname is set to build on
   top of (configured with `branch.<name>.remote` and
@@ -103,7 +103,7 @@ some output processing may assume ref names in UTF-8.
   current one. These suffixes are also accepted when spelled in uppercase, and
   they mean the same thing no matter the case.
 
-'[<branchname>]@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
+'[<branchname>]@\{push\}', e.g. `master@{push}`, '@\{push\}'::
   The suffix '@\{push}' reports the branch "where we would push to" if
   `git push` were run while `branchname` was checked out (or the current
   `HEAD` if no branchname is specified). Since our push destination is
@@ -131,7 +131,7 @@ from one location and push to another. In a non-triangular workflow,
 This suffix is also accepted when spelled in uppercase, and means the same
 thing no matter the case.
 
-'<rev>{caret}[<n>]', e.g. 'HEAD{caret}, v1.5.1{caret}0'::
+'<rev>{caret}[<n>]', e.g. `HEAD^`, 'v1.5.1{caret}0'::
   A suffix '{caret}' to a revision parameter means the first parent of
   that commit object.  '{caret}<n>' means the <n>th parent (i.e.
   '<rev>{caret}'
@@ -139,7 +139,7 @@ thing no matter the case.
   '<rev>{caret}0' means the commit itself and is used when '<rev>' is the
   object name of a tag object that refers to a commit object.
 
-'<rev>{tilde}[<n>]', e.g. 'HEAD{tilde}, master{tilde}3'::
+'<rev>{tilde}[<n>]', e.g. `HEAD~`, `master~3`::
   A suffix '{tilde}' to a revision parameter means the first parent of
   that commit object.
   A suffix '{tilde}<n>' to a revision parameter means the commit
@@ -175,7 +175,7 @@ existing tag object.
   and dereference the tag recursively until a non-tag object is
   found.
 
-'<rev>{caret}{/<text>}', e.g. 'HEAD^{/fix nasty bug}'::
+'<rev>{caret}{/<text>}', e.g. `HEAD^{/fix nasty bug}`::
   A suffix '{caret}' to a revision parameter, followed by a brace
   pair that contains a text led by a slash,
   is the same as the ':/fix nasty bug' syntax below except that
@@ -186,7 +186,7 @@ existing tag object.
   A colon, followed by a slash, followed by a text, names
   a commit whose commit message matches the specified regular expression.
   This name returns the youngest matching commit which is
-  reachable from any ref, including HEAD.
+  reachable from any ref, including `HEAD`.
   The regular expression can match any part of the
   commit message. To match messages starting with a string, one can use
   e.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what
@@ -196,7 +196,7 @@ existing tag object.
   Depending on the given text, the shell's word splitting rules might
   require additional quoting.
 
-'<rev>:<path>', e.g. 'HEAD:README', 'master:./README'::
+'<rev>:<path>', e.g. `HEAD:README`, `master:./README`::
   A suffix ':' followed by a path names the blob or tree
   at the given path in the tree-ish object named by the part
   before the colon.
@@ -287,12 +287,12 @@ The '...' (three-dot) Symmetric Difference Notation::
  It is the set of commits that are reachable from either one of
  'r1' (left side) or 'r2' (right side) but not from both.
 
-In these two shorthand notations, you can omit one end and let it default to HEAD.
-For example, 'origin..' is a shorthand for 'origin..HEAD' and asks "What
-did I do since I forked from the origin branch?"  Similarly, '..origin'
-is a shorthand for 'HEAD..origin' and asks "What did the origin do since
-I forked from them?"  Note that '..' would mean 'HEAD..HEAD' which is an
-empty range that is both reachable and unreachable from HEAD.
+In these two shorthand notations, you can omit one end and let it default to `HEAD`.
+For example, '`origin`..' is a shorthand for '`origin`..`HEAD`' and asks "What
+did I do since I forked from the `origin` branch?"  Similarly, '..`origin`'
+is a shorthand for '`HEAD`..`origin`' and asks "What did the `origin` do since
+I forked from them?"  Note that '..' would mean '`HEAD`..`HEAD`' which is an
+empty range that is both reachable and unreachable from `HEAD`.
 
 Other <rev>{caret} Parent Shorthand Notations
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -313,7 +313,7 @@ itself).
 
 While '<rev>{caret}<n>' was about specifying a single commit parent, these
 three notations also consider its parents. For example you can say
-'HEAD{caret}2{caret}@', however you cannot say 'HEAD{caret}@{caret}2'.
+`HEAD^2^@`, however you cannot say `HEAD^@^2`.
 
 Revision Range Summary
 ----------------------
@@ -336,17 +336,17 @@ Revision Range Summary
 	<rev2> but exclude those that are reachable from both.  When
 	either <rev1> or <rev2> is omitted, it defaults to `HEAD`.
 
-'<rev>{caret}@', e.g. 'HEAD{caret}@'::
+'<rev>{caret}@', e.g. `HEAD^@`::
   A suffix '{caret}' followed by an at sign is the same as listing
   all parents of '<rev>' (meaning, include anything reachable from
   its parents, but not the commit itself).
 
-'<rev>{caret}!', e.g. 'HEAD{caret}!'::
+'<rev>{caret}!', e.g. `HEAD^!`::
   A suffix '{caret}' followed by an exclamation mark is the same
   as giving commit '<rev>' and then all its parents prefixed with
   '{caret}' to exclude them (and their ancestors).
 
-'<rev>{caret}-<n>', e.g. 'HEAD{caret}-, HEAD{caret}-2'::
+'<rev>{caret}-<n>', e.g. `HEAD^-`, `HEAD^-2`::
 	Equivalent to '<rev>{caret}<n>..<rev>', with '<n>' = 1 if not
 	given.
 
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 0f9a699c09..62ddf41e75 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -280,7 +280,7 @@ a summary of the commands:
 	create a new branch `<new>` referencing `<start-point>`, and
 	check it out.
 
-The special symbol "HEAD" can always be used to refer to the current
+The special symbol `HEAD` can always be used to refer to the current
 branch.  In fact, Git uses a file named `HEAD` in the `.git` directory
 to remember which branch is current:
 
@@ -300,7 +300,7 @@ you can check out the commit referenced by a tag:
 $ git switch --detach v2.6.17
 Note: checking out 'v2.6.17'.
 
-You are in 'detached HEAD' state. You can look around, make experimental
+You are in 'detached `HEAD`' state. You can look around, make experimental
 changes and commit them, and you can discard any commits you make in this
 state without impacting any branches by performing another switch.
 
@@ -309,10 +309,10 @@ do so (now or later) by using `-c` with the switch command again. Example:
 
   git switch -c new_branch_name
 
-HEAD is now at 427abfa Linux v2.6.17
+`HEAD` is now at 427abfa Linux v2.6.17
 ------------------------------------------------
 
-The HEAD then refers to the SHA-1 of the commit instead of to a branch,
+The `HEAD` then refers to the SHA-1 of the commit instead of to a branch,
 and git branch shows that you are no longer on a branch:
 
 ------------------------------------------------
@@ -323,7 +323,7 @@ $ git branch
   master
 ------------------------------------------------
 
-In this case we say that the HEAD is "detached".
+In this case we say that the `HEAD` is "detached".
 
 This is an easy way to check out a particular version without having to
 make up a name for the new branch.   You can still create a new branch
@@ -332,8 +332,8 @@ make up a name for the new branch.   You can still create a new branch
 [[examining-remote-branches]]
 === Examining branches from a remote repository
 
-The "master" branch that was created at the time you cloned is a copy
-of the HEAD in the repository that you cloned from.  That repository
+The `master` branch that was created at the time you cloned is a copy
+of the `HEAD` in the repository that you cloned from.  That repository
 may also have had other branches, though, and your local repository
 keeps branches which track each of those remote branches, called
 remote-tracking branches, which you
@@ -351,7 +351,7 @@ $ git branch -r
   origin/todo
 ------------------------------------------------
 
-In this example, "origin" is called a remote repository, or "remote"
+In this example, `origin` is called a remote repository, or "remote"
 for short. The branches of this repository are called "remote
 branches" from our point of view. The remote-tracking branches listed
 above were created based on the remote branches at clone time and will
@@ -368,7 +368,7 @@ $ git switch -c my-todo-copy origin/todo
 You can also check out `origin/todo` directly to examine it or
 write a one-off patch.  See <<detached-head,detached head>>.
 
-Note that the name "origin" is just the name that Git uses by default
+Note that the name `origin` is just the name that Git uses by default
 to refer to the repository that you cloned from.
 
 [[how-git-stores-references]]
@@ -391,9 +391,9 @@ under the path given by their name.  However, for efficiency reasons
 they may also be packed together in a single file; see
 linkgit:git-pack-refs[1]).
 
-As another useful shortcut, the "HEAD" of a repository can be referred
-to just using the name of that repository.  So, for example, "origin"
-is usually a shortcut for the HEAD branch in the repository "origin".
+As another useful shortcut, the `HEAD` of a repository can be referred
+to just using the name of that repository.  So, for example, `origin`
+is usually a shortcut for the HEAD branch in the repository `origin`.
 
 For the complete list of paths which Git checks for references, and
 the order it uses to decide which to choose when there are multiple
@@ -491,9 +491,9 @@ Bisecting: 3537 revisions left to test after this
 -------------------------------------------------
 
 If you run `git branch` at this point, you'll see that Git has
-temporarily moved you in "(no branch)". HEAD is now detached from any
+temporarily moved you in "(no branch)". `HEAD` is now detached from any
 branch and points directly to a commit (with commit id 65934) that
-is reachable from "master" but not from v2.6.18. Compile and test it,
+is reachable from `master` but not from v2.6.18. Compile and test it,
 and see whether it crashes. Assume it does crash. Then:
 
 -------------------------------------------------
@@ -566,7 +566,7 @@ We have seen several ways of naming commits already:
 	- tag name: refers to the commit pointed to by the given tag
 	  (we've seen branches and tags are special cases of
 	  <<how-git-stores-references,references>>).
-	- HEAD: refers to the head of the current branch
+	- `HEAD`: refers to the head of the current branch
 
 There are many more; see the "SPECIFYING REVISIONS" section of the
 linkgit:gitrevisions[7] man page for the complete list of ways to
@@ -589,24 +589,24 @@ $ git show HEAD^1   # show the first parent of HEAD
 $ git show HEAD^2   # show the second parent of HEAD
 -------------------------------------------------
 
-In addition to HEAD, there are several other special names for
+In addition to `HEAD`, there are several other special names for
 commits:
 
 Merges (to be discussed later), as well as operations such as
 `git reset`, which change the currently checked-out commit, generally
-set ORIG_HEAD to the value HEAD had before the current operation.
+set `ORIG_HEAD` to the value `HEAD` had before the current operation.
 
 The `git fetch` operation always stores the head of the last fetched
-branch in FETCH_HEAD.  For example, if you run `git fetch` without
+branch in `FETCH_HEAD`.  For example, if you run `git fetch` without
 specifying a local branch as the target of the operation
 
 -------------------------------------------------
 $ git fetch git://example.com/proj.git theirbranch
 -------------------------------------------------
 
-the fetched commits will still be available from FETCH_HEAD.
+the fetched commits will still be available from `FETCH_HEAD`.
 
-When we discuss merges we'll also see the special name MERGE_HEAD,
+When we discuss merges we'll also see the special name `MERGE_HEAD`,
 which refers to the other branch that we're merging in to the current
 branch.
 
@@ -914,7 +914,7 @@ any version of a project; for example:
 $ git archive -o latest.tar.gz --prefix=project/ HEAD
 -------------------------------------------------
 
-will use HEAD to produce a gzipped tar archive in which each filename
+will use `HEAD` to produce a gzipped tar archive in which each filename
 is preceded by `project/`.  The output file format is inferred from
 the output file extension if possible, see linkgit:git-archive[1] for
 details.
@@ -1037,8 +1037,8 @@ at step 3, Git maintains a snapshot of the tree's contents in a
 special staging area called "the index."
 
 At the beginning, the content of the index will be identical to
-that of the HEAD.  The command `git diff --cached`, which shows
-the difference between the HEAD and the index, should therefore
+that of the `HEAD`.  The command `git diff --cached`, which shows
+the difference between the `HEAD` and the index, should therefore
 produce no output at that point.
 
 Modifying the index is easy:
@@ -1061,7 +1061,7 @@ After each step you can verify that
 $ git diff --cached
 -------------------------------------------------
 
-always shows the difference between the HEAD and the index file--this
+always shows the difference between the `HEAD` and the index file--this
 is what you'd commit if you created the commit now--and that
 
 -------------------------------------------------
@@ -1283,8 +1283,8 @@ index 802992c,2b60207..0000000
 
 Recall that the commit which will be committed after we resolve this
 conflict will have two parents instead of the usual one: one parent
-will be HEAD, the tip of the current branch; the other will be the
-tip of the other branch, which is stored temporarily in MERGE_HEAD.
+will be `HEAD`, the tip of the current branch; the other will be the
+tip of the other branch, which is stored temporarily in `MERGE_HEAD`.
 
 During the merge, the index holds three versions of each file.  Each of
 these three "file stages" represents a different version of the file:
@@ -1348,8 +1348,8 @@ $ git log --merge
 $ gitk --merge
 -------------------------------------------------
 
-These will display all commits which exist only on HEAD or on
-MERGE_HEAD, and which touch an unmerged file.
+These will display all commits which exist only on `HEAD` or on
+`MERGE_HEAD`, and which touch an unmerged file.
 
 You may also use linkgit:git-mergetool[1], which lets you merge the
 unmerged files using external tools such as Emacs or kdiff3.
@@ -1433,7 +1433,7 @@ commit; for example, to revert the most recent commit:
 $ git revert HEAD
 -------------------------------------------------
 
-This will create a new commit which undoes the change in HEAD.  You
+This will create a new commit which undoes the change in `HEAD`.  You
 will be given a chance to edit the commit message for the new commit.
 
 You can also revert an earlier change, for example, the next-to-last:
@@ -1486,7 +1486,7 @@ linkgit:git-restore[1]. The command
 $ git restore --source=HEAD^ path/to/file
 -------------------------------------------------
 
-replaces path/to/file by the contents it had in the commit HEAD^, and
+replaces path/to/file by the contents it had in the commit `HEAD^`, and
 also updates the index to match.  It does not change branches.
 
 If you just want to look at an old version of the file, without
@@ -1600,13 +1600,13 @@ $ gitk master@{"1 week ago"}	# ... or last week
 $ git log --walk-reflogs master	# show reflog entries for master
 -------------------------------------------------
 
-A separate reflog is kept for the HEAD, so
+A separate reflog is kept for the `HEAD`, so
 
 -------------------------------------------------
 $ git show HEAD@{"1 week ago"}
 -------------------------------------------------
 
-will show what HEAD pointed to one week ago, not what the current branch
+will show what `HEAD` pointed to one week ago, not what the current branch
 pointed to one week ago.  This allows you to see the history of what
 you've checked out.
 
@@ -1677,7 +1677,7 @@ into your own work.
 We have already seen <<Updating-a-repository-With-git-fetch,how to
 keep remote-tracking branches up to date>> with linkgit:git-fetch[1],
 and how to merge two branches.  So you can merge in changes from the
-original repository's master branch with:
+original repository's `master` branch with:
 
 -------------------------------------------------
 $ git fetch
@@ -1692,7 +1692,7 @@ $ git pull origin master
 -------------------------------------------------
 
 In fact, if you have `master` checked out, then this branch has been
-configured by `git clone` to get changes from the HEAD branch of the
+configured by `git clone` to get changes from the `HEAD` branch of the
 origin repository.  So often you can
 accomplish the above with just a simple
 
@@ -2568,7 +2568,7 @@ You can also edit a patch series with an interactive rebase.  This is
 the same as <<reordering-patch-series,reordering a patch series using
 `format-patch`>>, so use whichever interface you like best.
 
-Rebase your current HEAD on the last commit you want to retain as-is.
+Rebase your current `HEAD` on the last commit you want to retain as-is.
 For example, if you want to reorder the last 5 commits, use:
 
 -------------------------------------------------
@@ -2980,7 +2980,7 @@ file data at changing paths suggests a rename.  (See, for example, the
 `-M` option to linkgit:git-diff[1]).
 
 A commit is usually created by linkgit:git-commit[1], which creates a
-commit whose parent is normally the current HEAD, and whose tree is
+commit whose parent is normally the current `HEAD`, and whose tree is
 taken from the content currently stored in the index.
 
 [[tree-object]]
@@ -3507,7 +3507,7 @@ $ ls -a
 The `git submodule add <repo> <path>` command does a couple of things:
 
 - It clones the submodule from `<repo>` to the given `<path>` under the
-  current directory and by default checks out the master branch.
+  current directory and by default checks out the `master` branch.
 - It adds the submodule's clone path to the linkgit:gitmodules[5] file and
   adds this file to the index, ready to be committed.
 - It adds the submodule's current commit ID to the index, ready to be
@@ -3540,7 +3540,7 @@ $ git submodule status
 -------------------------------------------------
 
 NOTE: The commit object names shown above would be different for you, but they
-should match the HEAD commit object names of your repositories.  You can check
+should match the `HEAD` commit object names of your repositories.  You can check
 it by running `git ls-remote ../a`.
 
 Pulling down the submodules is a two-step process. First run `git submodule
@@ -4334,7 +4334,7 @@ $ git branch new		# create branch "new" starting at current HEAD
 $ git branch -d new		# delete branch "new"
 -----------------------------------------------
 
-Instead of basing a new branch on current HEAD (the default), use:
+Instead of basing a new branch on current `HEAD` (the default), use:
 
 -----------------------------------------------
 $ git branch new test    # branch named "test"
-- 
2.31.1.133.g84d06cdc06


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [RFC PATCH v1 03/13] doc: typeset configuration options in monospace
  2021-04-09  4:02 [RFC PATCH v1 00/13][GSoC] doc: (monospace) apply CodingGuidelines on a large-scale Firmin Martin
  2021-04-09  4:02 ` [RFC PATCH v1 01/13] doc: typeset command-line options in monospace Firmin Martin
  2021-04-09  4:02 ` [RFC PATCH v1 02/13] doc: typeset branches and remotes " Firmin Martin
@ 2021-04-09  4:02 ` Firmin Martin
  2021-04-09  4:02 ` [RFC PATCH v1 04/13] doc: typeset git-related commands " Firmin Martin
                   ` (10 subsequent siblings)
  13 siblings, 0 replies; 20+ messages in thread
From: Firmin Martin @ 2021-04-09  4:02 UTC (permalink / raw)
  To: git; +Cc: Firmin Martin

Wrap configuration options with backticks as indicated in the
CodingGuidelines.

Signed-off-by: Firmin Martin <firminmartin24@gmail.com>
---
 Documentation/blame-options.txt          |  4 +--
 Documentation/diff-options.txt           | 10 +++---
 Documentation/fetch-options.txt          |  4 +--
 Documentation/git-branch.txt             |  2 +-
 Documentation/git-clean.txt              |  2 +-
 Documentation/git-column.txt             |  6 ++--
 Documentation/git-commit.txt             |  8 ++---
 Documentation/git-config.txt             | 10 +++---
 Documentation/git-credential-cache.txt   |  2 +-
 Documentation/git-cvsexportcommit.txt    |  2 +-
 Documentation/git-fetch.txt              |  8 ++---
 Documentation/git-filter-branch.txt      |  4 +--
 Documentation/git-for-each-ref.txt       |  2 +-
 Documentation/git-fsck.txt               |  2 +-
 Documentation/git-grep.txt               |  4 +--
 Documentation/git-help.txt               |  4 +--
 Documentation/git-init.txt               |  2 +-
 Documentation/git-interpret-trailers.txt |  8 ++---
 Documentation/git-ls-files.txt           |  2 +-
 Documentation/git-ls-remote.txt          |  4 +--
 Documentation/git-mailinfo.txt           |  4 +--
 Documentation/git-mv.txt                 |  4 +--
 Documentation/git-notes.txt              | 12 +++----
 Documentation/git-p4.txt                 | 12 +++----
 Documentation/git-pull.txt               |  4 +--
 Documentation/git-push.txt               |  2 +-
 Documentation/git-rebase.txt             | 10 +++---
 Documentation/git-receive-pack.txt       |  2 +-
 Documentation/git-remote.txt             |  4 +--
 Documentation/git-rerere.txt             |  2 +-
 Documentation/git-rev-parse.txt          |  2 +-
 Documentation/git-rm.txt                 |  2 +-
 Documentation/git-send-email.txt         | 20 +++++------
 Documentation/git-status.txt             |  8 ++---
 Documentation/git-submodule.txt          |  4 +--
 Documentation/git-svn.txt                | 42 ++++++++++++------------
 Documentation/git-update-index.txt       |  4 +--
 Documentation/git-update-ref.txt         |  2 +-
 Documentation/git-web--browse.txt        |  4 +--
 Documentation/git.txt                    | 10 +++---
 Documentation/gitattributes.txt          | 10 +++---
 Documentation/gitcore-tutorial.txt       |  4 +--
 Documentation/gitcredentials.txt         |  2 +-
 Documentation/glossary-content.txt       |  2 +-
 Documentation/pull-fetch-param.txt       |  2 +-
 Documentation/user-manual.txt            |  2 +-
 46 files changed, 133 insertions(+), 133 deletions(-)

diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 860e8e2f5c..1d36a176bb 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -72,8 +72,8 @@ include::line-range-format.txt[]
 
 --date <format>::
 	Specifies the format used to output dates. If `--date` is not
-	provided, the value of the blame.date config variable is
-	used. If the blame.date config variable is also not set, the
+	provided, the value of the `blame.date` config variable is
+	used. If the `blame.date` config variable is also not set, the
 	iso format is used. For supported values, see the discussion
 	of the `--date` option at linkgit:git-log[1].
 
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index e4ac746428..86c19bed1e 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -344,20 +344,20 @@ default::
 	in the future.
 plain::
 	Any line that is added in one location and was removed
-	in another location will be colored with 'color.diff.newMoved'.
-	Similarly 'color.diff.oldMoved' will be used for removed lines
+	in another location will be colored with `color.diff.newMoved`.
+	Similarly `color.diff.oldMoved` will be used for removed lines
 	that are added somewhere else in the diff. This mode picks up any
 	moved line, but it is not very useful in a review to determine
 	if a block of code was moved without permutation.
 blocks::
 	Blocks of moved text of at least 20 alphanumeric characters
 	are detected greedily. The detected blocks are
-	painted using either the 'color.diff.{old,new}Moved' color.
+	painted using either the `color.diff.{old,new}Moved` color.
 	Adjacent blocks cannot be told apart.
 zebra::
 	Blocks of moved text are detected as in 'blocks' mode. The blocks
-	are painted using either the 'color.diff.{old,new}Moved' color or
-	'color.diff.{old,new}MovedAlternative'. The change between
+	are painted using either the `color.diff.{old,new}Moved` color or
+	`color.diff.{old,new}MovedAlternative`. The change between
 	the two colors indicates that a new block was detected.
 dimmed-zebra::
 	Similar to 'zebra', but additional dimming of uninteresting parts
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 4ccd65c166..60a268cc4a 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -266,13 +266,13 @@ endif::git-pull[]
 
 --show-forced-updates::
 	By default, git checks if a branch is force-updated during
-	fetch. This can be disabled through fetch.showForcedUpdates, but
+	fetch. This can be disabled through `fetch.showForcedUpdates`, but
 	the `--show-forced-updates` option guarantees this check occurs.
 	See linkgit:git-config[1].
 
 --no-show-forced-updates::
 	By default, git checks if a branch is force-updated during
-	fetch. Pass `--no-show-forced-updates` or set fetch.showForcedUpdates
+	fetch. Pass `--no-show-forced-updates` or set `fetch.showForcedUpdates`
 	to false to skip this check for performance reasons. If used during
 	'git-pull' the `--ff-only` option will still check for forced updates
 	before attempting a fast-forward update. See linkgit:git-config[1].
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index fa38fa4dc1..8ea6e1e523 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -215,7 +215,7 @@ This option is only applicable in non-verbose mode.
 	upstream when the new branch is checked out.
 +
 This behavior is the default when the start point is a remote-tracking branch.
-Set the branch.autoSetupMerge configuration variable to `false` if you
+Set the `branch.autoSetupMerge` configuration variable to `false` if you
 want `git switch`, `git checkout` and `git branch` to always behave as if `--no-track`
 were given. Set it to `always` if you want this behavior when the
 start-point is either a local or remote-tracking branch.
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index f4246300ae..cbec3e649a 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -35,7 +35,7 @@ OPTIONS
 
 -f::
 --force::
-	If the Git configuration variable clean.requireForce is not set
+	If the Git configuration variable `clean.requireForce` is not set
 	to false, 'git clean' will refuse to delete files or directories
 	unless given `-f` or `-i`.  Git will refuse to modify untracked
 	nested git repositories (directories with a .git subdirectory)
diff --git a/Documentation/git-column.txt b/Documentation/git-column.txt
index 84a02ac15c..ab545fc52d 100644
--- a/Documentation/git-column.txt
+++ b/Documentation/git-column.txt
@@ -21,11 +21,11 @@ columns.
 OPTIONS
 -------
 --command=<name>::
-	Look up layout mode using configuration variable column.<name> and
-	column.ui.
+	Look up layout mode using configuration variable `column.<name>` and
+	`column.ui`.
 
 --mode=<mode>::
-	Specify layout mode. See configuration variable column.ui for option
+	Specify layout mode. See configuration variable `column.ui` for option
 	syntax in linkgit:git-config[1].
 
 --raw-mode=<n>::
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index f507ae00a1..6d10f2bdc7 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -244,7 +244,7 @@ verbatim::
 scissors::
 	Same as `whitespace` except that everything from (and including)
 	the line found below is truncated, if the message is to be edited.
-	"`#`" can be customized with core.commentChar.
+	"`#`" can be customized with `core.commentChar`.
 
 		# ------------------------ >8 ------------------------
 
@@ -346,7 +346,7 @@ The possible options are:
 	- 'normal' - Shows untracked files and directories
 	- 'all'    - Also shows individual files in untracked directories.
 
-The default can be changed using the status.showUntrackedFiles
+The default can be changed using the `status.showUntrackedFiles`
 configuration variable documented in linkgit:git-config[1].
 --
 
@@ -378,7 +378,7 @@ changes to tracked files.
 	Include the output of linkgit:git-status[1] in the commit
 	message template when using an editor to prepare the commit
 	message.  Defaults to on, but can be used to override
-	configuration variable commit.status.
+	configuration variable `commit.status`.
 
 --no-status::
 	Do not include the output of linkgit:git-status[1] in the
@@ -552,7 +552,7 @@ include::i18n.txt[]
 ENVIRONMENT AND CONFIGURATION VARIABLES
 ---------------------------------------
 The editor used to edit the commit log message will be chosen from the
-`GIT_EDITOR` environment variable, the core.editor configuration variable, the
+`GIT_EDITOR` environment variable, the `core.editor` configuration variable, the
 `VISUAL` environment variable, or the `EDITOR` environment variable (in that
 order).  See linkgit:git-var[1] for details.
 
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index e6d70ffda1..606411c816 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -99,10 +99,10 @@ OPTIONS
 	names are not.
 
 --get-urlmatch name URL::
-	When given a two-part name section.key, the value for
-	section.<url>.key whose <url> part matches the best to the
+	When given a two-part name `section.key`, the value for
+	`section.<url>.key` whose <url> part matches the best to the
 	given URL is returned (if no such key exists, the value for
-	section.key is used as a fallback).  When given just the
+	`section.key` is used as a fallback).  When given just the
 	section as name, do so for all the keys in the section and
 	list them.  Returns error code 1 if no value is found.
 
@@ -421,7 +421,7 @@ To delete the entry for renames, do
 % git config --unset diff.renames
 ------------
 
-If you want to delete an entry for a multivar (like core.gitproxy above),
+If you want to delete an entry for a multivar (like `core.gitproxy` above),
 you have to provide a regex matching the value of exactly one line.
 
 To query the value for a given key, do
@@ -448,7 +448,7 @@ If you want to know all the values for a multivar, do:
 % git config --get-all core.gitproxy
 ------------
 
-If you like to live dangerously, you can replace *all* core.gitproxy by a
+If you like to live dangerously, you can replace *all* `core.gitproxy` by a
 new one with
 
 ------------
diff --git a/Documentation/git-credential-cache.txt b/Documentation/git-credential-cache.txt
index 0216c18ef8..b1a9d9b29a 100644
--- a/Documentation/git-credential-cache.txt
+++ b/Documentation/git-credential-cache.txt
@@ -68,7 +68,7 @@ $ git push http://example.com/repo.git
 [your credentials are used automatically]
 ------------------------------------
 
-You can provide options via the credential.helper configuration
+You can provide options via the `credential.helper` configuration
 variable (this example drops the cache time to 5 minutes):
 
 -------------------------------------------------------
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index f08ab508af..76b16f9dae 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -72,7 +72,7 @@ OPTIONS
 	Specify the location of the CVS checkout to use for the export. This
 	option does not require GIT_DIR to be set before execution if the
 	current directory is within a Git repository.  The default is the
-	value of 'cvsexportcommit.cvsdir'.
+	value of `cvsexportcommit.cvsdir`.
 
 -W::
 	Tell cvsexportcommit that the current working directory is not only
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index a5ecf00db3..6c3f41399f 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -26,13 +26,13 @@ By default, any tag that points into the histories being fetched is
 also fetched; the effect is to fetch tags that
 point at branches that you are interested in.  This default behavior
 can be changed by using the `--tags` or `--no-tags` options or by
-configuring remote.<name>.tagOpt.  By using a refspec that fetches tags
+configuring `remote.<name>.tagOpt`.  By using a refspec that fetches tags
 explicitly, you can fetch tags that do not point into branches you
 are interested in as well.
 
 'git fetch' can fetch from either a single named repository or URL,
 or from several repositories at once if <group> is given and
-there is a remotes.<group> entry in the configuration file.
+there is a `remotes.<group>` entry in the configuration file.
 (See linkgit:git-config[1]).
 
 When no remote is specified, by default the `origin` remote will be used,
@@ -208,7 +208,7 @@ The status of up-to-date refs is shown only if the `--verbose` option is
 used.
 
 In compact output mode, specified with configuration variable
-fetch.output, if either entire `<from>` or `<to>` is found in the
+`fetch.output`, if either entire `<from>` or `<to>` is found in the
 other string, it will be substituted with `*` in the other string. For
 example, `master -> origin/master` becomes `master -> origin/*`.
 
@@ -253,7 +253,7 @@ $ git fetch origin
 +
 The above command copies all branches from the remote refs/heads/
 namespace and stores them to the local refs/remotes/origin/ namespace,
-unless the branch.<name>.fetch option is used to specify a non-default
+unless the `branch.<name>.fetch` option is used to specify a non-default
 refspec.
 
 * Using refspecs explicitly:
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index e2955bc648..520d3df371 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -365,7 +365,7 @@ git filter-branch --msg-filter '
 
 The `--env-filter` option can be used to modify committer and/or author
 identity.  For example, if you found out that your commits have the wrong
-identity due to a misconfigured user.email, you can make a correction,
+identity due to a misconfigured `user.email`, you can make a correction,
 before publishing the project, like this:
 
 --------------------------------------------------------
@@ -577,7 +577,7 @@ with:
   ls-files will only quote filenames if needed, so folks may not
   notice that one of the files didn't match the regex (at least not
   until it's much too late).  Yes, someone who knows about
-  core.quotePath can avoid this (unless they have other special
+  `core.quotePath` can avoid this (unless they have other special
   characters like \t, \n, or "), and people who use ls-files -z with
   something other than grep can avoid this, but that doesn't mean they
   will.
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 4bde4f9d05..64ff4a14f8 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -105,7 +105,7 @@ For all objects, the following names can be used:
 refname::
 	The name of the ref (the part after $GIT_DIR/).
 	For a non-ambiguous short name of the ref append `:short`.
-	The option core.warnAmbiguousRefs is used to select the strict
+	The option `core.warnAmbiguousRefs` is used to select the strict
 	abbreviation mode. If `lstrip=<N>` (`rstrip=<N>`) is appended, strips `<N>`
 	slash-separated path components from the front (back) of the refname
 	(e.g. `%(refname:lstrip=2)` turns `refs/tags/foo` into `foo` and
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index e932c75181..d9a28e278d 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -123,7 +123,7 @@ Any corrupt objects you will have to find in backups or other archives
 (i.e., you can just remove them and do an 'rsync' with some other site in
 the hopes that somebody else has the object you have corrupted).
 
-If core.commitGraph is true, the commit-graph file will also be inspected
+If `core.commitGraph` is true, the commit-graph file will also be inspected
 using 'git commit-graph verify'. See linkgit:git-commit-graph[1].
 
 Extracted Diagnostics
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 84102cc596..88047cefad 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -209,7 +209,7 @@ providing this option will cause it to die.
 	Use \0 as the delimiter for pathnames in the output, and print
 	them verbatim. Without this option, pathnames with "unusual"
 	characters are quoted as explained for the configuration
-	variable core.quotePath (see linkgit:git-config[1]).
+	variable `core.quotePath` (see linkgit:git-config[1]).
 
 -o::
 --only-matching::
@@ -355,7 +355,7 @@ EXAMPLES
 NOTES ON THREADS
 ----------------
 
-The `--threads` option (and the grep.threads configuration) will be ignored when
+The `--threads` option (and the `grep.threads` configuration) will be ignored when
 `--open-files-in-pager` is used, forcing a single-threaded execution.
 
 When grepping the object store (with `--cached` or giving tree objects), running
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index a19f275f60..392f7be6fa 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -150,7 +150,7 @@ man.<tool>.path
 You can explicitly provide a full path to your preferred man viewer by
 setting the configuration variable `man.<tool>.path`. For example, you
 can configure the absolute path to konqueror by setting
-'man.konqueror.path'. Otherwise, 'git help' assumes the tool is
+`man.konqueror.path`. Otherwise, 'git help' assumes the tool is
 available in PATH.
 
 man.<tool>.cmd
@@ -170,7 +170,7 @@ When 'konqueror' is specified in the `man.viewer` configuration
 variable, we launch 'kfmclient' to try to open the man page on an
 already opened konqueror in a new tab if possible.
 
-For consistency, we also try such a trick if 'man.konqueror.path' is
+For consistency, we also try such a trick if `man.konqueror.path` is
 set to something like `A_PATH_TO/konqueror`. That means we will try to
 launch `A_PATH_TO/kfmclient` instead.
 
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index a3f061517d..47d61fc505 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -83,7 +83,7 @@ customized via the `init.defaultBranch` configuration variable).
 
 Specify that the Git repository is to be shared amongst several users.  This
 allows users belonging to the same group to push into that
-repository.  When specified, the config variable "core.sharedRepository" is
+repository.  When specified, the config variable `core.sharedRepository` is
 set so that files and directories under `$GIT_DIR` are created with the
 requested permissions.  When not specified, Git will use permissions reported
 by umask(2).
diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt
index 4288e5405c..1160807e0d 100644
--- a/Documentation/git-interpret-trailers.txt
+++ b/Documentation/git-interpret-trailers.txt
@@ -217,17 +217,17 @@ If there is a separator, then the key will be used instead of both the
 <token> and the default separator when adding the trailer.
 
 trailer.<token>.where::
-	This option takes the same values as the 'trailer.where'
+	This option takes the same values as the `trailer.where`
 	configuration variable and it overrides what is specified by
 	that option for trailers with the specified <token>.
 
 trailer.<token>.ifexists::
-	This option takes the same values as the 'trailer.ifexists'
+	This option takes the same values as the `trailer.ifexists`
 	configuration variable and it overrides what is specified by
 	that option for trailers with the specified <token>.
 
 trailer.<token>.ifmissing::
-	This option takes the same values as the 'trailer.ifmissing'
+	This option takes the same values as the `trailer.ifmissing`
 	configuration variable and it overrides what is specified by
 	that option for trailers with the specified <token>.
 
@@ -247,7 +247,7 @@ replaced with the <value> part of an existing trailer with the same
 <token>, if any, before the command is launched.
 +
 If some '<token>=<value>' arguments are also passed on the command
-line, when a 'trailer.<token>.command' is configured, the command will
+line, when a `trailer.<token>.command` is configured, the command will
 also be executed for each of these arguments. And the <value> part of
 these arguments, if any, will be used to replace the `$ARG` string in
 the command.
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index b42f179aef..d27a33eb22 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -173,7 +173,7 @@ a space) at the start of each line:
 --eol::
 	Show <eolinfo> and <eolattr> of files.
 	<eolinfo> is the file content identification used by Git when
-	the "text" attribute is "auto" (or not set and core.autocrlf is not false).
+	the "text" attribute is "auto" (or not set and `core.autocrlf` is not false).
 	<eolinfo> is either "-text", "none", "lf", "crlf", "mixed" or "".
 +
 "" means the file is not a regular file, it is not in the index or
diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
index af005ece9a..dbe0c69298 100644
--- a/Documentation/git-ls-remote.txt
+++ b/Documentation/git-ls-remote.txt
@@ -53,7 +53,7 @@ OPTIONS
 
 --get-url::
 	Expand the URL of the given remote repository taking into account any
-	"url.<base>.insteadOf" config setting (See linkgit:git-config[1]) and
+	`url.<base>.insteadOf` config setting (See linkgit:git-config[1]) and
 	exit without talking to the remote.
 
 --symref::
@@ -66,7 +66,7 @@ OPTIONS
 	Sort based on the key given. Prefix `-` to sort in descending order
 	of the value. Supports "version:refname" or "v:refname" (tag names
 	are treated as versions). The "version:refname" sort order can also
-	be affected by the "versionsort.suffix" configuration variable.
+	be affected by the `versionsort.suffix` configuration variable.
 	See linkgit:git-for-each-ref[1] for more sort options, but be aware
 	keys like `committerdate` that require access to the objects
 	themselves will not work for refs whose objects have not yet been
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 5bc2982909..c54feb665b 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -84,10 +84,10 @@ with comments and suggestions on the message you are responding to, and to
 conclude it with a patch submission, separating the discussion and the
 beginning of the proposed commit log message with a scissors line.
 +
-This can be enabled by default with the configuration option mailinfo.scissors.
+This can be enabled by default with the configuration option `mailinfo.scissors`.
 
 --no-scissors::
-	Ignore scissors lines. Useful for overriding mailinfo.scissors settings.
+	Ignore scissors lines. Useful for overriding `mailinfo.scissors` settings.
 
 <msg>::
 	The commit log message extracted from e-mail, usually
diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt
index b3808dcc06..ceb039a697 100644
--- a/Documentation/git-mv.txt
+++ b/Documentation/git-mv.txt
@@ -48,8 +48,8 @@ SUBMODULES
 ----------
 Moving a submodule using a gitfile (which means they were cloned
 with a Git version 1.7.8 or newer) will update the gitfile and
-core.worktree setting to make the submodule work in the new location.
-It also will attempt to update the submodule.<name>.path setting in
+`core.worktree` setting to make the submodule work in the new location.
+It also will attempt to update the `submodule.<name>.path` setting in
 the linkgit:gitmodules[5] file and stage that file (unless `-n` is used).
 
 BUGS
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index ef04e3a8ff..ac1d191352 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -44,9 +44,9 @@ using the `--notes` option. Such notes are added as a patch commentary
 after a three dash separator line.
 
 To change which notes are shown by 'git log', see the
-"notes.displayRef" configuration in linkgit:git-log[1].
+`notes.displayRef` configuration in linkgit:git-log[1].
 
-See the "notes.rewrite.<command>" configuration for a way to carry
+See the `notes.rewrite.<command>` configuration for a way to carry
 notes across commands that rewrite commits.
 
 
@@ -161,7 +161,7 @@ OPTIONS
 
 --ref <ref>::
 	Manipulate the notes tree in <ref>.  This overrides
-	`GIT_NOTES_REF` and the "core.notesRef" configuration.  The ref
+	`GIT_NOTES_REF` and the `core.notesRef` configuration.  The ref
 	specifies the full refname when it begins with `refs/notes/`; when it
 	begins with `notes/`, `refs/` and otherwise `refs/notes/` is prefixed
 	to form a full name of the ref.
@@ -185,7 +185,7 @@ OPTIONS
 	When merging notes, resolve notes conflicts using the given
 	strategy. The following strategies are recognized: "manual"
 	(default), "ours", "theirs", "union" and "cat_sort_uniq".
-	This option overrides the "notes.mergeStrategy" configuration setting.
+	This option overrides the `notes.mergeStrategy` configuration setting.
 	See the "NOTES MERGE STRATEGIES" section below for more
 	information on each notes merge strategy.
 
@@ -251,7 +251,7 @@ When done, the user can either finalize the merge with
 'git notes merge --abort'.
 
 Users may select an automated merge strategy from among the following using
-either `-s`/`--strategy` option or configuring notes.mergeStrategy accordingly:
+either `-s`/`--strategy` option or configuring `notes.mergeStrategy` accordingly:
 
 "ours" automatically resolves conflicting notes in favor of the local
 version (i.e. the current notes ref).
@@ -327,7 +327,7 @@ This setting can be overridden by passing the `--strategy` option.
 notes.<name>.mergeStrategy::
 	Which merge strategy to choose when doing a notes merge into
 	refs/notes/<name>.  This overrides the more general
-	"notes.mergeStrategy".  See the "NOTES MERGE STRATEGIES" section above
+	`notes.mergeStrategy`.  See the "NOTES MERGE STRATEGIES" section above
 	for more information on each available strategy.
 
 notes.displayRef::
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index ec23ab7d96..326c553083 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -135,7 +135,7 @@ Submit
 Submitting changes from a Git repository back to the p4 repository
 requires a separate p4 client workspace.  This should be specified
 using the `P4CLIENT` environment variable or the Git configuration
-variable 'git-p4.client'.  The p4 client must exist, but the client root
+variable `git-p4.client`.  The p4 client must exist, but the client root
 will be created and populated if it does not already exist.
 
 To submit all changes that are in the current Git branch but not in
@@ -367,12 +367,12 @@ These options can be used to modify 'git p4 submit' behavior.
 
 --disable-rebase::
     Disable the automatic rebase after all commits have been successfully
-    submitted. Can also be set with git-p4.disableRebase.
+    submitted. Can also be set with `git-p4.disableRebase`.
 
 --disable-p4sync::
     Disable the automatic sync of p4/master from Perforce after commits have
     been submitted. Implies `--disable-rebase`. Can also be set with
-    git-p4.disableP4Sync. Sync with origin/master still goes ahead if possible.
+    `git-p4.disableP4Sync`. Sync with origin/master still goes ahead if possible.
 
 Hooks for submit
 ----------------
@@ -490,7 +490,7 @@ paths map through overlays to the same location in the repository,
 dedicating a client spec just for 'git p4'.
 
 The name of the client can be given to 'git p4' in multiple ways.  The
-variable 'git-p4.client' takes precedence if it exists.  Otherwise,
+variable `git-p4.client` takes precedence if it exists.  Otherwise,
 normal p4 mechanisms of determining the client are used:  environment
 variable `P4CLIENT`, a file referenced by `P4CONFIG`, or the local host name.
 
@@ -530,7 +530,7 @@ called 'master', and one for //depot/branch1 called 'depot/branch1'.
 However, it is not necessary to create branches in p4 to be able to use
 them like branches.  Because it is difficult to infer branch
 relationships automatically, a Git configuration setting
-'git-p4.branchList' can be used to explicitly identify branch
+`git-p4.branchList` can be used to explicitly identify branch
 relationships.  It is a list of "source:destination" pairs, like a
 simple p4 branch specification, where the "source" and "destination" are
 the path elements in the p4 repository.  The example above relied on the
@@ -748,7 +748,7 @@ git-p4.disableRebase::
     Do not rebase the tree against p4/master following a submit.
 
 git-p4.disableP4Sync::
-    Do not sync p4/master with Perforce following a submit. Implies git-p4.disableRebase.
+    Do not sync p4/master with Perforce following a submit. Implies `git-p4.disableRebase`.
 
 IMPLEMENTATION DETAILS
 ----------------------
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index d9a5507195..e637686597 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -212,8 +212,8 @@ $ git pull origin
 ------------------------------------------------
 +
 Normally the branch merged in is the `HEAD` of the remote repository,
-but the choice is determined by the branch.<name>.remote and
-branch.<name>.merge options; see linkgit:git-config[1] for details.
+but the choice is determined by the `branch.<name>.remote` and
+`branch.<name>.merge` options; see linkgit:git-config[1] for details.
 
 * Merge into the current branch the remote branch `next`:
 +
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 91dcaa108c..aa5db3e6e5 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -411,7 +411,7 @@ Specifying `--no-force-if-includes` disables this behavior.
 	also be aborted and exit with non-zero status. If 'only' is used all
 	submodules will be recursively pushed while the superproject is left
 	unpushed. A value of 'no' or using `--no-recurse-submodules` can be used
-	to override the push.recurseSubmodules configuration variable when no
+	to override the `push.recurseSubmodules` configuration variable when no
 	submodule recursion is required.
 
 --[no-]verify::
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index bd9f15ea26..22287372f7 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -21,7 +21,7 @@ If <branch> is specified, 'git rebase' will perform an automatic
 it remains on the current branch.
 
 If <upstream> is not specified, the upstream configured in
-branch.<name>.remote and branch.<name>.merge options will be used (see
+`branch.<name>.remote` and `branch.<name>.merge` options will be used (see
 linkgit:git-config[1] for details) and the `--fork-point` option is
 assumed.  If you are currently not on any branch or if the current
 branch does not have a configured upstream, the rebase will abort.
@@ -404,7 +404,7 @@ See also INCOMPATIBLE OPTIONS below.
 
 --stat::
 	Show a diffstat of what changed upstream since the last rebase. The
-	diffstat is also controlled by the configuration option rebase.stat.
+	diffstat is also controlled by the configuration option `rebase.stat`.
 
 -n::
 --no-stat::
@@ -509,7 +509,7 @@ See also INCOMPATIBLE OPTIONS below.
 	split commits (see SPLITTING COMMITS below).
 +
 The commit list format can be changed by setting the configuration option
-rebase.instructionFormat.  A customized instruction format will automatically
+`rebase.instructionFormat`.  A customized instruction format will automatically
 have the long commit hash prepended to the format.
 +
 See also INCOMPATIBLE OPTIONS below.
@@ -721,7 +721,7 @@ order to apply the changes to the right lines.  However, if multiple
 areas of the code have the same surrounding lines of context, the
 wrong one can be picked.  There are real-world cases where this has
 caused commits to be reapplied incorrectly with no conflicts reported.
-Setting diff.context to a larger value may prevent such types of
+Setting `diff.context` to a larger value may prevent such types of
 problems, but increases the chance of spurious conflicts (since it
 will require more lines of matching context to apply).
 
@@ -737,7 +737,7 @@ content came from.  Since the apply backend drops the original
 information about the rebased commits and their parents (and instead
 generates new fake commits based off limited information in the
 generated patches), those commits cannot be identified; instead it has
-to fall back to a commit summary.  Also, when merge.conflictStyle is
+to fall back to a commit summary.  Also, when `merge.conflictStyle` is
 set to diff3, the apply backend will use "constructed merge base" to
 label the content from the merge base, and thus provide no information
 about the merge base commit whatsoever.
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index 25702ed730..e6136a0938 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -29,7 +29,7 @@ the send-pack end, it is updating the remote.  Confused?)
 There are other real-world examples of using update and
 post-update hooks found in the Documentation/howto directory.
 
-'git-receive-pack' honours the receive.denyNonFastForwards config
+'git-receive-pack' honours the `receive.denyNonFastForwards` config
 option, which tells it if updates to a ref should be denied if they
 are not fast-forwards.
 
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 31c29c9b31..a28c72a9e4 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -188,8 +188,8 @@ actually prune them.
 
 Fetch updates for remotes or remote groups in the repository as defined by
 `remotes.<group>`. If neither group nor remote is specified on the command line,
-the configuration parameter remotes.default will be used; if
-remotes.default is not defined, all remotes which do not have the
+the configuration parameter `remotes.default` will be used; if
+`remotes.default` is not defined, all remotes which do not have the
 configuration parameter `remote.<name>.skipDefaultUpdate` set to true will
 be updated.  (See linkgit:git-config[1]).
 +
diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
index c5c6be5202..25990dc40b 100644
--- a/Documentation/git-rerere.txt
+++ b/Documentation/git-rerere.txt
@@ -181,7 +181,7 @@ records the hand resolve when it is a new conflict, or reuses the earlier hand
 resolve when it is not.  'git commit' also invokes 'git rerere'
 when committing a merge result.  What this means is that you do
 not have to do anything special yourself (besides enabling
-the rerere.enabled config variable).
+the `rerere.enabled` config variable).
 
 In our example, when you do the test merge, the manual
 resolution is recorded, and it will be reused when you do the
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 7c3c0e0007..5f6224847e 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -143,7 +143,7 @@ for another option.
 
 --abbrev-ref[=(strict|loose)]::
 	A non-ambiguous short name of the objects name.
-	The option core.warnAmbiguousRefs is used to select the strict
+	The option `core.warnAmbiguousRefs` is used to select the strict
 	abbreviation mode.
 
 --symbolic::
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index ea1f349a87..56d9b0627f 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -149,7 +149,7 @@ tree, as their repository lives inside the .git directory of the
 superproject. If a submodule (or one of those nested inside it)
 still uses a .git directory, `git rm` will move the submodules
 git directory into the superprojects git directory to protect
-the submodule's history. If it exists the submodule.<name> section
+the submodule's history. If it exists the `submodule.<name>` section
 in the linkgit:gitmodules[5] file will also be removed and that file
 will be staged (unless `--cached` or `-n` are used).
 
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index afd41a010e..9d9ef3d945 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -128,14 +128,14 @@ This option may be specified multiple times.
 	When encountering a non-ASCII message or subject that does not
 	declare its encoding, add headers/quoting to indicate it is
 	encoded in <encoding>.  Default is the value of the
-	'sendemail.assume8bitEncoding'; if that is unspecified, this
+	`sendemail.assume8bitEncoding`; if that is unspecified, this
 	will be prompted for if any non-ASCII files are encountered.
 +
 Note that no attempts whatsoever are made to validate the encoding.
 
 --compose-encoding=<encoding>::
 	Specify encoding of compose message. Default is the value of the
-	'sendemail.composeencoding'; if that is unspecified, UTF-8 is assumed.
+	`sendemail.composeencoding`; if that is unspecified, UTF-8 is assumed.
 
 --transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)::
 	Specify the transfer encoding to be used to send the message over SMTP.
@@ -189,7 +189,7 @@ $ git send-email --smtp-auth="PLAIN LOGIN GSSAPI" ...
 +
 If at least one of the specified mechanisms matches the ones advertised by the
 SMTP server and if it is supported by the utilized SASL library, the mechanism
-is used for authentication. If neither 'sendemail.smtpAuth' nor `--smtp-auth`
+is used for authentication. If neither `sendemail.smtpAuth` nor `--smtp-auth`
 is specified, all mechanisms supported by the SASL library can be used. The
 special value 'none' maybe specified to completely disable authentication
 independently of `--smtp-user`
@@ -290,7 +290,7 @@ Automating
 	Specify a command to execute once per patch file which
 	should generate patch file specific "To:" entries.
 	Output of this command must be single email address per line.
-	Default is the value of 'sendemail.tocmd' configuration value.
+	Default is the value of `sendemail.tocmd` configuration value.
 
 --cc-cmd=<command>::
 	Specify a command to execute once per patch file which
@@ -308,8 +308,8 @@ Automating
 
 --identity=<identity>::
 	A configuration identity. When given, causes values in the
-	'sendemail.<identity>' subsection to take precedence over
-	values in the 'sendemail' section. The default identity is
+	`sendemail.<identity>` subsection to take precedence over
+	values in the `sendemail` section. The default identity is
 	the value of `sendemail.identity`.
 
 --[no-]signed-off-by-cc::
@@ -320,13 +320,13 @@ Automating
 --[no-]cc-cover::
 	If this is set, emails found in Cc: headers in the first patch of
 	the series (typically the cover letter) are added to the cc list
-	for each email set. Default is the value of 'sendemail.cccover'
+	for each email set. Default is the value of `sendemail.cccover`
 	configuration value; if that is unspecified, default to `--no-cc-cover`.
 
 --[no-]to-cover::
 	If this is set, emails found in To: headers in the first patch of
 	the series (typically the cover letter) are added to the to list
-	for each email set. Default is the value of 'sendemail.tocover'
+	for each email set. Default is the value of `sendemail.tocover`
 	configuration value; if that is unspecified, default to `--no-to-cover`.
 
 --suppress-cc=<category>::
@@ -437,7 +437,7 @@ Information
 	Instead of the normal operation, dump the shorthand alias names from
 	the configured alias file(s), one per line in alphabetical order. Note,
 	this only includes the alias name and not its expanded email addresses.
-	See 'sendemail.aliasesfile' for more information about aliases.
+	See `sendemail.aliasesfile` for more information about aliases.
 
 
 CONFIGURATION
@@ -448,7 +448,7 @@ sendemail.aliasesFile::
 	email aliases files.  You must also supply `sendemail.aliasFileType`.
 
 sendemail.aliasFileType::
-	Format of the file(s) specified in sendemail.aliasesFile. Must be
+	Format of the file(s) specified in `sendemail.aliasesFile`. Must be
 	one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus', or 'sendmail'.
 +
 What an alias file in each format looks like can be found in
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 4b1951c5ce..0c9b68e981 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -80,7 +80,7 @@ Consider enabling untracked cache and split index if supported (see
 --split-index`), Otherwise you can use `no` to have `git status`
 return more quickly without showing untracked files.
 
-The default can be changed using the status.showUntrackedFiles
+The default can be changed using the `status.showUntrackedFiles`
 configuration variable documented in linkgit:git-config[1].
 --
 
@@ -163,7 +163,7 @@ at any time.
 The paths mentioned in the output, unlike many other Git commands, are
 made relative to the current directory if you are working in a
 subdirectory (this is on purpose, to help cutting and pasting). See
-the status.relativePaths config option below.
+the `status.relativePaths` config option below.
 
 Short Format
 ~~~~~~~~~~~~
@@ -265,10 +265,10 @@ based on user configuration. This makes it ideal for parsing by scripts.
 The description of the short format above also describes the porcelain
 format, with a few exceptions:
 
-1. The user's color.status configuration is not respected; color will
+1. The user's `color.status` configuration is not respected; color will
    always be off.
 
-2. The user's status.relativePaths configuration is not respected; paths
+2. The user's `status.relativePaths` configuration is not respected; paths
    shown will always be relative to the repository root.
 
 There is also an alternate `-z` format recommended for machine parsing. In
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 891c9e48e5..e68d91a406 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -101,7 +101,7 @@ init [--] [<path>...]::
 	repository will be assumed to be upstream.
 +
 Optional <path> arguments limit which submodules will be initialized.
-If no path is specified and submodule.active has been configured, submodules
+If no path is specified and `submodule.active` has been configured, submodules
 configured to be active will be initialized, otherwise all submodules are
 initialized.
 +
@@ -182,7 +182,7 @@ set-branch (-b|--branch) <branch> [--] <path>::
 set-branch (-d|--default) [--] <path>::
 	Sets the default remote tracking branch for the submodule. The
 	`--branch` option allows the remote branch to be specified. The
-	`--default` option removes the submodule.<name>.branch configuration
+	`--default` option removes the `submodule.<name>.branch` configuration
 	key, which causes the tracking branch to default to the remote `HEAD`.
 
 set-url [--] <path> <newurl>::
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index f316b7dfc4..91495cfa01 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -1,4 +1,4 @@
-git-svn(1)
+g-it-svn(1)
 ==========
 
 NAME
@@ -57,7 +57,7 @@ COMMANDS
 	as well, they take precedence.
 --no-metadata;;
 	Set the 'noMetadata' option in the [svn-remote] config.
-	This option is not recommended, please read the 'svn.noMetadata'
+	This option is not recommended, please read the `svn.noMetadata`
 	section of this manpage before using this option.
 --use-svm-props;;
 	Set the 'useSvmProps' option in the [svn-remote] config.
@@ -149,7 +149,7 @@ the same local time zone.
 	can be used to allow only certain refs.
 +
 [verse]
-config key: svn-remote.<name>.ignore-refs
+config key: `svn-remote.<name>.ignore-refs`
 +
 If the ignore-refs configuration key is set, and the command-line
 option is also given, both regular expressions will be used.
@@ -162,7 +162,7 @@ option is also given, both regular expressions will be used.
 	'rebase', etc) on a given repository.
 +
 [verse]
-config key: svn-remote.<name>.ignore-paths
+config key: `svn-remote.<name>.ignore-paths`
 +
 If the ignore-paths configuration key is set, and the command-line
 option is also given, both regular expressions will be used.
@@ -192,7 +192,7 @@ Skip "branches" and "tags" of first level directories;;
 	precedence over `--include-paths`.
 +
 [verse]
-config key: svn-remote.<name>.include-paths
+config key: `svn-remote.<name>.include-paths`
 
 --log-window-size=<n>;;
 	Fetch <n> log entries per request when scanning Subversion history.
@@ -268,12 +268,12 @@ Use of 'dcommit' is preferred to 'set-tree' (below).
 	method (e.g. `svn+ssh://` or `https://`) for commit.
 +
 [verse]
-config key: svn-remote.<name>.commiturl
-config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options)
+config key: `svn-remote.<name>.commiturl`
+config key: `svn.commiturl` (overwrites all `svn-remote.<name>.commiturl` options)
 +
 Note that the SVN URL of the commiturl config key includes the SVN branch.
 If you rather want to set the commit URL for an entire SVN repository use
-svn-remote.<name>.pushurl instead.
+`svn-remote.<name>.pushurl` instead.
 +
 Using this option for any other purpose (don't ask) is very strongly
 discouraged.
@@ -287,7 +287,7 @@ discouraged.
 	(`--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"`)
 +
 [verse]
-config key: svn.pushmergeinfo
+config key: `svn.pushmergeinfo`
 +
 This option will cause git-svn to attempt to automatically populate the
 svn:mergeinfo property in the SVN repository when possible. Currently, this can
@@ -447,7 +447,7 @@ Any other arguments are passed directly to 'git log'
 	Empty directories are automatically recreated when using
 	"git svn clone" and "git svn rebase", so "mkdirs" is intended
 	for use after commands like "git checkout" or "git reset".
-	(See the svn-remote.<name>.automkdirs config file option for
+	(See the `svn-remote.<name>.automkdirs` config file option for
 	more information.)
 
 'commit-diff'::
@@ -609,7 +609,7 @@ cannot version empty directories.  Enabling this flag will make
 the commit to SVN act like Git.
 +
 [verse]
-config key: svn.rmdir
+config key: `svn.rmdir`
 
 -e::
 --edit::
@@ -620,7 +620,7 @@ default for objects that are commits, and forced on when committing
 tree objects.
 +
 [verse]
-config key: svn.edit
+config key: `svn.edit`
 
 -l<num>::
 --find-copies-harder::
@@ -630,8 +630,8 @@ They are both passed directly to 'git diff-tree'; see
 linkgit:git-diff-tree[1] for more information.
 +
 [verse]
-config key: svn.l
-config key: svn.findcopiesharder
+config key: `svn.l`
+config key: `svn.findcopiesharder`
 
 -A<filename>::
 --authors-file=<filename>::
@@ -649,7 +649,7 @@ appropriate entry.  Re-running the previous 'git svn' command
 after the authors-file is modified should continue operation.
 +
 [verse]
-config key: svn.authorsfile
+config key: `svn.authorsfile`
 
 --authors-prog=<filename>::
 	If this option is specified, for each SVN committer name that
@@ -665,7 +665,7 @@ to the root of the working tree for 'fetch'. If 'filename' is
 not found, it is searched like any other command in '$PATH'.
 +
 [verse]
-config key: svn.authorsProg
+config key: `svn.authorsProg`
 
 -q::
 --quiet::
@@ -705,7 +705,7 @@ creating the branch or tag.
 	in the log message and use that as the author string.
 +
 [verse]
-config key: svn.useLogAuthor
+config key: `svn.useLogAuthor`
 
 --add-author-from::
 	When committing to svn from Git (as part of 'set-tree' or 'dcommit'
@@ -715,7 +715,7 @@ config key: svn.useLogAuthor
 	will retrieve a valid author string for all commits.
 +
 [verse]
-config key: svn.addAuthorFrom
+config key: `svn.addAuthorFrom`
 
 ADVANCED OPTIONS
 ----------------
@@ -750,7 +750,7 @@ ADVANCED OPTIONS
 	`--no-follow-parent` to disable it.
 +
 [verse]
-config key: svn.followparent
+config key: `svn.followparent`
 
 CONFIG FILE-ONLY OPTIONS
 ------------------------
@@ -774,7 +774,7 @@ reports, and archives.  If you plan to eventually migrate from SVN to
 Git and are certain about dropping SVN history, consider
 https://github.com/newren/git-filter-repo[git-filter-repo] instead.
 filter-repo also allows reformatting of metadata for ease-of-reading
-and rewriting authorship info for non-"svn.authorsFile" users.
+and rewriting authorship info for non-`svn.authorsFile` users.
 
 svn.useSvmProps::
 svn-remote.<name>.useSvmProps::
@@ -1159,7 +1159,7 @@ $GIT_DIR/svn/\**/.rev_map.*::
 	Mapping between Subversion revision numbers and Git commit
 	names.  In a repository where the noMetadata option is not set,
 	this can be rebuilt from the git-svn-id: lines that are at the
-	end of every commit (see the 'svn.noMetadata' section above for
+	end of every commit (see the `svn.noMetadata` section above for
 	details).
 +
 'git svn fetch' and 'git svn rebase' automatically update the rev_map
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 936b64045e..4eae32e711 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -422,12 +422,12 @@ all index entries and stays unchanged.
 
 All changes in the split index are pushed back to the shared index
 file when the number of entries in the split index reaches a level
-specified by the splitIndex.maxPercentChange config variable (see
+specified by the `splitIndex.maxPercentChange` config variable (see
 linkgit:git-config[1]).
 
 Each time a new shared index file is created, the old shared index
 files are deleted if their modification time is older than what is
-specified by the splitIndex.sharedIndexExpire config variable (see
+specified by the `splitIndex.sharedIndexExpire` config variable (see
 linkgit:git-config[1]).
 
 To avoid deleting a shared index file that is still used, its
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index be48daa825..f8aeea4cb4 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -149,7 +149,7 @@ still see a subset of the modifications.
 
 LOGGING UPDATES
 ---------------
-If config parameter "core.logAllRefUpdates" is true and the ref is one
+If config parameter `core.logAllRefUpdates` is true and the ref is one
 under "refs/heads/", "refs/remotes/", "refs/notes/", or a pseudoref
 like `HEAD` or `ORIG_HEAD`; or the file "$GIT_DIR/logs/<ref>" exists then
 `git update-ref` will append a line to the log file
diff --git a/Documentation/git-web--browse.txt b/Documentation/git-web--browse.txt
index d53b2570df..6fbe8d5583 100644
--- a/Documentation/git-web--browse.txt
+++ b/Documentation/git-web--browse.txt
@@ -71,7 +71,7 @@ browser.<tool>.path
 You can explicitly provide a full path to your preferred browser by
 setting the configuration variable `browser.<tool>.path`. For example,
 you can configure the absolute path to firefox by setting
-'browser.firefox.path'. Otherwise, 'git web{litdd}browse' assumes the tool
+`browser.firefox.path`. Otherwise, 'git web{litdd}browse' assumes the tool
 is available in PATH.
 
 browser.<tool>.cmd
@@ -91,7 +91,7 @@ When 'konqueror' is specified by a command-line option or a
 configuration variable, we launch 'kfmclient' to try to open the HTML
 man page on an already opened konqueror in a new tab if possible.
 
-For consistency, we also try such a trick if 'browser.konqueror.path' is
+For consistency, we also try such a trick if `browser.konqueror.path` is
 set to something like `A_PATH_TO/konqueror`. That means we will try to
 launch `A_PATH_TO/kfmclient` instead.
 
diff --git a/Documentation/git.txt b/Documentation/git.txt
index dcc52adff6..6aafa3a15c 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -154,8 +154,8 @@ If you just want to run git as if it was started in `<path>` then use
 	Set the path to the working tree. It can be an absolute path
 	or a path relative to the current working directory.
 	This can also be controlled by setting the GIT_WORK_TREE
-	environment variable and the core.worktree configuration
-	variable (see core.worktree in linkgit:git-config[1] for a
+	environment variable and the `core.worktree` configuration
+	variable (see `core.worktree` in linkgit:git-config[1] for a
 	more detailed discussion).
 
 --namespace=<path>::
@@ -210,7 +210,7 @@ If you just want to run git as if it was started in `<path>` then use
 	others (all other commands in `$PATH` that have git- prefix),
 	list-<category> (see categories in command-list.txt),
 	nohelpers (exclude helper commands), alias and config
-	(retrieve command list from config variable completion.commands)
+	(retrieve command list from config variable `completion.commands`)
 
 GIT COMMANDS
 ------------
@@ -482,7 +482,7 @@ double-quotes and respecting backslash escapes. E.g., the value
 `GIT_WORK_TREE`::
 	Set the path to the root of the working tree.
 	This can also be controlled by the `--work-tree` command-line
-	option and the core.worktree configuration variable.
+	option and the `core.worktree` configuration variable.
 
 `GIT_NAMESPACE`::
 	Set the Git namespace; see linkgit:gitnamespaces[7] for details.
@@ -609,7 +609,7 @@ other
 ~~~~~
 `GIT_MERGE_VERBOSITY`::
 	A number controlling the amount of output shown by
-	the recursive merge strategy.  Overrides merge.verbosity.
+	the recursive merge strategy.  Overrides `merge.verbosity`.
 	See linkgit:git-merge[1]
 
 `GIT_PAGER`::
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 0a60472bb5..f77d8487bd 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -199,7 +199,7 @@ convert them to CRLF when files are checked out.
 
 If you simply want to have CRLF line endings in your working directory
 regardless of the repository you are working with, you can set the
-config variable "core.autocrlf" without using any attributes.
+config variable `core.autocrlf` without using any attributes.
 
 ------------------------
 [core]
@@ -424,7 +424,7 @@ filter driver definition in the config, or a filter driver that exits with
 a non-zero status, is not an error but makes the filter a no-op passthru.
 
 You can declare that a filter turns a content that by itself is unusable
-into a usable content by setting the filter.<driver>.required configuration
+into a usable content by setting the `filter.<driver>.required` configuration
 variable to `true`.
 
 Note: Whenever the clean filter is changed, the repo should be renormalized:
@@ -437,7 +437,7 @@ attribute for paths.
 *.c	filter=indent
 ------------------------
 
-Then you would define a "filter.indent.clean" and "filter.indent.smudge"
+Then you would define a `filter.indent.clean` and `filter.indent.smudge`
 configuration in your .git/config to specify a pair of commands to
 modify the contents of C programs when the source files are checked
 in ("clean" is run) and checked out (no change is made because the
@@ -723,7 +723,7 @@ Unspecified::
 
 	A path to which the `diff` attribute is unspecified
 	first gets its contents inspected, and if it looks like
-	text and is smaller than core.bigFileThreshold, it is treated
+	text and is smaller than `core.bigFileThreshold`, it is treated
 	as text. Otherwise it would generate `Binary files differ`.
 
 String::
@@ -778,7 +778,7 @@ for paths.
 *.tex	diff=tex
 ------------------------
 
-Then, you would define a "diff.tex.xfuncname" configuration to
+Then, you would define a `diff.tex.xfuncname` configuration to
 specify a regular expression that matches a line that you would
 want to appear as the hunk header "TEXT". Add a section to your
 `$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 77573c813c..d1d81cbe15 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1479,7 +1479,7 @@ on that project and has an own "public repository" goes like this:
 
 1. Prepare your work repository, by running 'git clone' on the public
    repository of the "project lead". The URL used for the
-   initial cloning is stored in the remote.origin.url
+   initial cloning is stored in the `remote.origin.url`
    configuration variable.
 
 2. Prepare a public repository accessible to others, just like
@@ -1520,7 +1520,7 @@ like this:
 1. Prepare your work repository, by 'git clone' the public
    repository of the "project lead" (or a "subsystem
    maintainer", if you work on a subsystem). The URL used for
-   the initial cloning is stored in the remote.origin.url
+   the initial cloning is stored in the `remote.origin.url`
    configuration variable.
 
 2. Do your work in your repository on `master` branch.
diff --git a/Documentation/gitcredentials.txt b/Documentation/gitcredentials.txt
index 758bf39ba3..dffbdfbd0b 100644
--- a/Documentation/gitcredentials.txt
+++ b/Documentation/gitcredentials.txt
@@ -80,7 +80,7 @@ You may also have third-party helpers installed; search for
 `credential-*` in the output of `git help -a`, and consult the
 documentation of individual helpers.  Once you have selected a helper,
 you can tell Git to use it by putting its name into the
-credential.helper variable.
+`credential.helper` variable.
 
 1. Find a helper.
 +
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 88ee109fdf..5d719b4140 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -662,7 +662,7 @@ The most notable example is `HEAD`.
 [[def_upstream_branch]]upstream branch::
 	The default <<def_branch,branch>> that is merged into the branch in
 	question (or the branch in question is rebased onto). It is configured
-	via branch.<name>.remote and branch.<name>.merge. If the upstream branch
+	via `branch.<name>.remote` and `branch.<name>.merge`. If the upstream branch
 	of 'A' is 'origin/B' sometimes we say "'A' is tracking 'origin/B'".
 
 [[def_working_tree]]working tree::
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index 95a7390b2c..bbf418e48c 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -7,7 +7,7 @@
 ifndef::git-pull[]
 <group>::
 	A name referring to a list of repositories as the value
-	of remotes.<group> in the configuration file.
+	of `remotes.<group>` in the configuration file.
 	(See linkgit:git-config[1]).
 endif::git-pull[]
 
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 62ddf41e75..82b20b80df 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1949,7 +1949,7 @@ Note that the target of a `push` is normally a
 <<def_bare_repository,bare>> repository.  You can also push to a
 repository that has a checked-out working tree, but a push to update the
 currently checked-out branch is denied by default to prevent confusion.
-See the description of the receive.denyCurrentBranch option
+See the description of the `receive.denyCurrentBranch` option
 in linkgit:git-config[1] for details.
 
 As with `git fetch`, you may also set up configuration options to
-- 
2.31.1.133.g84d06cdc06


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [RFC PATCH v1 04/13] doc: typeset git-related commands in monospace
  2021-04-09  4:02 [RFC PATCH v1 00/13][GSoC] doc: (monospace) apply CodingGuidelines on a large-scale Firmin Martin
                   ` (2 preceding siblings ...)
  2021-04-09  4:02 ` [RFC PATCH v1 03/13] doc: typeset configuration options " Firmin Martin
@ 2021-04-09  4:02 ` Firmin Martin
  2021-04-09  4:02 ` [RFC PATCH v1 05/13] doc: typeset git-svn subcommands " Firmin Martin
                   ` (9 subsequent siblings)
  13 siblings, 0 replies; 20+ messages in thread
From: Firmin Martin @ 2021-04-09  4:02 UTC (permalink / raw)
  To: git; +Cc: Firmin Martin

Wrap git-related commands with backticks as indicated in the
CodingGuidelines.

Signed-off-by: Firmin Martin <firminmartin24@gmail.com>
---
 Documentation/MyFirstContribution.txt         |   8 +-
 Documentation/config.txt                      |   2 +-
 Documentation/diff-format.txt                 |   8 +-
 Documentation/diff-generate-patch.txt         |   4 +-
 Documentation/diff-options.txt                |   8 +-
 Documentation/fetch-options.txt               |  18 +-
 Documentation/git-add.txt                     |   6 +-
 Documentation/git-am.txt                      |  20 +-
 Documentation/git-apply.txt                   |  14 +-
 Documentation/git-archimport.txt              |  12 +-
 Documentation/git-archive.txt                 |   6 +-
 Documentation/git-bisect-lk2009.txt           | 164 ++++++++--------
 Documentation/git-bisect.txt                  |  38 ++--
 Documentation/git-blame.txt                   |  10 +-
 Documentation/git-branch.txt                  |  28 +--
 Documentation/git-bugreport.txt               |   4 +-
 Documentation/git-bundle.txt                  |  34 ++--
 Documentation/git-cat-file.txt                |   6 +-
 Documentation/git-check-attr.txt              |   4 +-
 Documentation/git-check-ignore.txt            |   4 +-
 Documentation/git-check-mailmap.txt           |   2 +-
 Documentation/git-check-ref-format.txt        |   8 +-
 Documentation/git-checkout-index.txt          |  10 +-
 Documentation/git-checkout.txt                |  42 ++--
 Documentation/git-cherry-pick.txt             |   6 +-
 Documentation/git-cherry.txt                  |   8 +-
 Documentation/git-citool.txt                  |   6 +-
 Documentation/git-clean.txt                   |  14 +-
 Documentation/git-clone.txt                   |   2 +-
 Documentation/git-column.txt                  |   4 +-
 Documentation/git-commit-graph.txt            |   4 +-
 Documentation/git-commit-tree.txt             |   6 +-
 Documentation/git-commit.txt                  |  16 +-
 Documentation/git-config.txt                  |  42 ++--
 Documentation/git-count-objects.txt           |   2 +-
 .../git-credential-cache--daemon.txt          |   2 +-
 Documentation/git-credential-cache.txt        |   2 +-
 Documentation/git-credential-store.txt        |   4 +-
 Documentation/git-credential.txt              |  16 +-
 Documentation/git-cvsexportcommit.txt         |   4 +-
 Documentation/git-cvsimport.txt               |  20 +-
 Documentation/git-cvsserver.txt               |  56 +++---
 Documentation/git-daemon.txt                  |  52 ++---
 Documentation/git-describe.txt                |  22 +--
 Documentation/git-diff-files.txt              |   4 +-
 Documentation/git-diff-index.txt              |  20 +-
 Documentation/git-diff-tree.txt               |  12 +-
 Documentation/git-diff.txt                    |  30 +--
 Documentation/git-difftool.txt                |  34 ++--
 Documentation/git-fast-export.txt             |  28 +--
 Documentation/git-fast-import.txt             |  36 ++--
 Documentation/git-fetch-pack.txt              |  18 +-
 Documentation/git-fetch.txt                   |  14 +-
 Documentation/git-filter-branch.txt           |  92 ++++-----
 Documentation/git-fmt-merge-msg.txt           |   8 +-
 Documentation/git-for-each-ref.txt            |   4 +-
 Documentation/git-for-each-repo.txt           |   2 +-
 Documentation/git-format-patch.txt            |  22 +--
 Documentation/git-fsck-objects.txt            |   2 +-
 Documentation/git-fsck.txt                    |   8 +-
 Documentation/git-gc.txt                      |  18 +-
 Documentation/git-get-tar-commit-id.txt       |   8 +-
 Documentation/git-grep.txt                    |  10 +-
 Documentation/git-gui.txt                     |  24 +--
 Documentation/git-hash-object.txt             |   6 +-
 Documentation/git-help.txt                    |  18 +-
 Documentation/git-http-backend.txt            |  38 ++--
 Documentation/git-http-fetch.txt              |   6 +-
 Documentation/git-http-push.txt               |   2 +-
 Documentation/git-imap-send.txt               |   4 +-
 Documentation/git-index-pack.txt              |  10 +-
 Documentation/git-init-db.txt                 |   2 +-
 Documentation/git-init.txt                    |   8 +-
 Documentation/git-instaweb.txt                |  10 +-
 Documentation/git-interpret-trailers.txt      |  10 +-
 Documentation/git-log.txt                     |  10 +-
 Documentation/git-ls-files.txt                |  12 +-
 Documentation/git-ls-remote.txt               |   6 +-
 Documentation/git-ls-tree.txt                 |   8 +-
 Documentation/git-mailinfo.txt                |   6 +-
 Documentation/git-mailsplit.txt               |   2 +-
 Documentation/git-maintenance.txt             |   2 +-
 Documentation/git-merge-base.txt              |  20 +-
 Documentation/git-merge-file.txt              |  12 +-
 Documentation/git-merge-index.txt             |  10 +-
 Documentation/git-merge-one-file.txt          |   6 +-
 Documentation/git-merge-tree.txt              |   4 +-
 Documentation/git-merge.txt                   |  54 +++---
 Documentation/git-mergetool--lib.txt          |   4 +-
 Documentation/git-mergetool.txt               |  20 +-
 Documentation/git-mktag.txt                   |   2 +-
 Documentation/git-mktree.txt                  |   2 +-
 Documentation/git-multi-pack-index.txt        |   4 +-
 Documentation/git-mv.txt                      |   8 +-
 Documentation/git-name-rev.txt                |   6 +-
 Documentation/git-notes.txt                   |  52 ++---
 Documentation/git-p4.txt                      | 132 ++++++-------
 Documentation/git-pack-objects.txt            |   8 +-
 Documentation/git-pack-redundant.txt          |   4 +-
 Documentation/git-pack-refs.txt               |   2 +-
 Documentation/git-patch-id.txt                |  12 +-
 Documentation/git-prune-packed.txt            |   2 +-
 Documentation/git-prune.txt                   |  16 +-
 Documentation/git-pull.txt                    |  18 +-
 Documentation/git-push.txt                    |  24 +--
 Documentation/git-quiltimport.txt             |   4 +-
 Documentation/git-range-diff.txt              |   2 +-
 Documentation/git-read-tree.txt               |  54 +++---
 Documentation/git-rebase.txt                  |  48 ++---
 Documentation/git-receive-pack.txt            |  28 +--
 Documentation/git-reflog.txt                  |  12 +-
 Documentation/git-remote-ext.txt              |  26 +--
 Documentation/git-remote-fd.txt               |  12 +-
 Documentation/git-remote.txt                  |  28 +--
 Documentation/git-repack.txt                  |  14 +-
 Documentation/git-replace.txt                 |  22 +--
 Documentation/git-request-pull.txt            |   2 +-
 Documentation/git-rerere.txt                  |  34 ++--
 Documentation/git-reset.txt                   |  22 +--
 Documentation/git-restore.txt                 |   6 +-
 Documentation/git-rev-list.txt                |   6 +-
 Documentation/git-rev-parse.txt               |  34 ++--
 Documentation/git-revert.txt                  |  10 +-
 Documentation/git-rm.txt                      |   4 +-
 Documentation/git-send-email.txt              |  28 +--
 Documentation/git-send-pack.txt               |  12 +-
 Documentation/git-sh-i18n--envsubst.txt       |   2 +-
 Documentation/git-sh-i18n.txt                 |   2 +-
 Documentation/git-sh-setup.txt                |   2 +-
 Documentation/git-shell.txt                   |  24 +--
 Documentation/git-shortlog.txt                |  10 +-
 Documentation/git-show-branch.txt             |  22 +--
 Documentation/git-show-index.txt              |   2 +-
 Documentation/git-show-ref.txt                |   8 +-
 Documentation/git-show.txt                    |  10 +-
 Documentation/git-sparse-checkout.txt         |   6 +-
 Documentation/git-stage.txt                   |   2 +-
 Documentation/git-stash.txt                   |  28 +--
 Documentation/git-status.txt                  |   6 +-
 Documentation/git-stripspace.txt              |   8 +-
 Documentation/git-submodule.txt               |  44 ++---
 Documentation/git-svn.txt                     | 176 ++++++++---------
 Documentation/git-switch.txt                  |  10 +-
 Documentation/git-symbolic-ref.txt            |   8 +-
 Documentation/git-tag.txt                     |  22 +--
 Documentation/git-unpack-file.txt             |   2 +-
 Documentation/git-unpack-objects.txt          |   2 +-
 Documentation/git-update-index.txt            |  42 ++--
 Documentation/git-update-ref.txt              |   2 +-
 Documentation/git-update-server-info.txt      |   2 +-
 Documentation/git-upload-archive.txt          |   8 +-
 Documentation/git-upload-pack.txt             |   8 +-
 Documentation/git-var.txt                     |   2 +-
 Documentation/git-verify-commit.txt           |   4 +-
 Documentation/git-verify-pack.txt             |   4 +-
 Documentation/git-verify-tag.txt              |   4 +-
 Documentation/git-web--browse.txt             |   8 +-
 Documentation/git-whatchanged.txt             |   6 +-
 Documentation/git-worktree.txt                |  18 +-
 Documentation/git-write-tree.txt              |  10 +-
 Documentation/git.txt                         |  36 ++--
 Documentation/gitattributes.txt               |  22 +--
 Documentation/gitcore-tutorial.txt            | 164 ++++++++--------
 Documentation/gitcredentials.txt              |   8 +-
 Documentation/gitcvs-migration.txt            |  14 +-
 Documentation/gitdiffcore.txt                 |  32 ++--
 Documentation/giteveryday.txt                 |   8 +-
 Documentation/gitfaq.txt                      |   2 +-
 Documentation/githooks.txt                    |  10 +-
 Documentation/gitignore.txt                   |   6 +-
 Documentation/gitk.txt                        |  24 +--
 Documentation/gitmodules.txt                  |   2 +-
 Documentation/gitnamespaces.txt               |   8 +-
 Documentation/gitremote-helpers.txt           |  32 ++--
 Documentation/gitrepository-layout.txt        |  22 +--
 Documentation/gittutorial-2.txt               |  22 +--
 Documentation/gittutorial.txt                 |  56 +++---
 Documentation/gitweb.conf.txt                 | 180 +++++++++---------
 Documentation/gitweb.txt                      |  90 ++++-----
 Documentation/gitworkflows.txt                |   6 +-
 Documentation/glossary-content.txt            |   8 +-
 Documentation/i18n.txt                        |   4 +-
 Documentation/merge-options.txt               |   4 +-
 Documentation/pull-fetch-param.txt            |  10 +-
 Documentation/revisions.txt                   |   2 +-
 Documentation/urls-remotes.txt                |  12 +-
 Documentation/urls.txt                        |   2 +-
 Documentation/user-manual.txt                 |  30 +--
 188 files changed, 1731 insertions(+), 1731 deletions(-)

diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt
index af0a9da62e..06f9f370d7 100644
--- a/Documentation/MyFirstContribution.txt
+++ b/Documentation/MyFirstContribution.txt
@@ -481,7 +481,7 @@ git-psuh - Delight users' typo with a shy horse
 SYNOPSIS
 --------
 [verse]
-'git-psuh [<arg>...]'
+`git-psuh [<arg>...]`
 
 DESCRIPTION
 -----------
@@ -590,7 +590,7 @@ you the rest of the options afterwards, untouched.
 
 Now that you have a usage hint, you can teach Git how to show it in the general
 command list shown by `git help git` or `git help -a`, which is generated from
-`command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
+`command-list.txt`. Find the line for `git-pull` so you can add your `git-psuh`
 line above it in alphabetical order. Now, we can add some attributes about the
 command which impacts where it shows up in the aforementioned help commands. The
 top of `command-list.txt` shares some information about what each attribute
@@ -652,7 +652,7 @@ Create a new file `t/t9999-psuh-tutorial.sh`. Begin with the header as so (see
 
 test_description='git-psuh test
 
-This test runs git-psuh and makes sure it does not crash.'
+This test runs `git-psuh` and makes sure it does not crash.'
 
 . ./test-lib.sh
 ----
@@ -971,7 +971,7 @@ Here's an example body for `psuh`:
 
 ----
 Our internal metrics indicate widespread interest in the command
-git-psuh - that is, many users are trying to use it, but finding it is
+`git-psuh` - that is, many users are trying to use it, but finding it is
 unavailable, using some unknown workaround instead.
 
 The following handful of patches add the psuh command and implement some
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bf82766a6a..05bcf1bf2b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -249,7 +249,7 @@ boolean::
 		`0` and the empty string.
 +
 When converting a value to its canonical form using the `--type=bool` type
-specifier, 'git config' will ensure that the output is "true" or
+specifier, `git config` will ensure that the output is "true" or
 "false" (spelled in lowercase).
 
 integer::
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index fbbd410a84..14ef11d552 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -1,8 +1,8 @@
 Raw output format
 -----------------
 
-The raw output format from "git-diff-index", "git-diff-tree",
-"git-diff-files" and "git diff --raw" are very similar.
+The raw output format from `git-diff-index`, `git-diff-tree`,
+`git-diff-files` and `git diff --raw` are very similar.
 
 These commands all compare two sets of things; what is
 compared differs:
@@ -19,7 +19,7 @@ git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]::
 git-diff-files [<pattern>...]::
         compares the index and the files on the filesystem.
 
-The "git-diff-tree" command begins its output by printing the hash of
+The `git-diff-tree` command begins its output by printing the hash of
 what is being compared. After that, all the commands print one output
 line per changed file.
 
@@ -86,7 +86,7 @@ verbatim and the line is terminated by a NUL byte.
 diff format for merges
 ----------------------
 
-"git-diff-tree", "git-diff-files" and "git-diff --raw"
+`git-diff-tree`, `git-diff-files` and `git-diff --raw`
 can take `-c` or `--cc` option
 to generate diff output also for merge commits.  The output differs
 from the format described above in the following way:
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
index 2615b29cb0..da1572b765 100644
--- a/Documentation/diff-generate-patch.txt
+++ b/Documentation/diff-generate-patch.txt
@@ -16,7 +16,7 @@ You can customize the creation of patch text via the
 What the `-p` option produces is slightly different from the traditional
 diff format:
 
-1.   It is preceded with a "git diff" header that looks like this:
+1.   It is preceded with a `git diff` header that looks like this:
 
        diff --git a/file1 b/file2
 +
@@ -117,7 +117,7 @@ index fabadb8,cc95eb0..4866510
 		for_each_ref(get_name);
 ------------
 
-1.   It is preceded with a "git diff" header, that looks like
+1.   It is preceded with a `git diff` header, that looks like
      this (when the `-c` option is used):
 
        diff --combined file
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 86c19bed1e..34570aa445 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -825,10 +825,10 @@ endif::git-format-patch[]
 	Prepend an additional prefix to every line of output.
 
 --ita-invisible-in-index::
-	By default entries added by "git add -N" appear as an existing
-	empty file in "git diff" and a new file in "git diff --cached".
-	This option makes the entry appear as a new file in "git diff"
-	and non-existent in "git diff --cached". This option could be
+	By default entries added by `git add -N` appear as an existing
+	empty file in `git diff` and a new file in `git diff --cached`.
+	This option makes the entry appear as a new file in `git diff`
+	and non-existent in `git diff --cached`. This option could be
 	reverted with `--ita-visible-in-index`. Both options are
 	experimental and could be removed in future.
 
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 60a268cc4a..6aa07a54b9 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -79,7 +79,7 @@ endif::git-pull[]
 
 -f::
 --force::
-	When 'git fetch' is used with `<src>:<dst>` refspec it may
+	When `git fetch` is used with `<src>:<dst>` refspec it may
 	refuse to update the local branch as discussed
 ifdef::git-pull[]
 	in the `<refspec>` part of the linkgit:git-fetch[1]
@@ -223,25 +223,25 @@ ifndef::git-pull[]
 
 -u::
 --update-head-ok::
-	By default 'git fetch' refuses to update the head which
+	By default `git fetch` refuses to update the head which
 	corresponds to the current branch.  This flag disables the
-	check.  This is purely for the internal use for 'git pull'
-	to communicate with 'git fetch', and unless you are
+	check.  This is purely for the internal use for `git pull`
+	to communicate with `git fetch`, and unless you are
 	implementing your own Porcelain you are not supposed to
 	use it.
 endif::git-pull[]
 
 --upload-pack <upload-pack>::
 	When given, and the repository to fetch from is handled
-	by 'git fetch-pack', `--exec=<upload-pack>` is passed to
+	by `git fetch-pack`, `--exec=<upload-pack>` is passed to
 	the command to specify non-default path for the command
 	run on the other end.
 
 ifndef::git-pull[]
 -q::
 --quiet::
-	Pass `--quiet` to git-fetch-pack and silence any other internally
-	used git commands. Progress is not reported to the standard error
+	Pass `--quiet` to `git-fetch-pack` and silence any other internally
+	used `git` commands. Progress is not reported to the standard error
 	stream.
 
 -v::
@@ -265,13 +265,13 @@ endif::git-pull[]
 	sent to the other side in the order listed on the command line.
 
 --show-forced-updates::
-	By default, git checks if a branch is force-updated during
+	By default, `git` checks if a branch is force-updated during
 	fetch. This can be disabled through `fetch.showForcedUpdates`, but
 	the `--show-forced-updates` option guarantees this check occurs.
 	See linkgit:git-config[1].
 
 --no-show-forced-updates::
-	By default, git checks if a branch is force-updated during
+	By default, `git` checks if a branch is force-updated during
 	fetch. Pass `--no-show-forced-updates` or set `fetch.showForcedUpdates`
 	to false to skip this check for performance reasons. If used during
 	'git-pull' the `--ff-only` option will still check for forced updates
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 8ec99c5c12..786c31fc60 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -41,7 +41,7 @@ The `git add` command will not add ignored files by default.  If any
 ignored files were explicitly specified on the command line, `git add`
 will fail with a list of ignored files.  Ignored files reached by
 directory recursion or filename globbing performed by Git (quote your
-globs before the shell) will be silently ignored.  The 'git add' command can
+globs before the shell) will be silently ignored.  The `git add` command can
 be used to add ignored files with the `-f` (force) option.
 
 Please see linkgit:git-commit[1] for alternative ways to add content to a
@@ -141,8 +141,8 @@ subdirectories).
 	option is a no-op when no <pathspec> is used.
 +
 This option is primarily to help users who are used to older
-versions of Git, whose "git add <pathspec>..." was a synonym
-for "git add --no-all <pathspec>...", i.e. ignored removed files.
+versions of Git, whose `git add <pathspec>...` was a synonym
+for `git add --no-all <pathspec>...`, i.e. ignored removed files.
 
 -N::
 --intent-to-add::
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index cd56054be0..80f2f89cbd 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -39,13 +39,13 @@ OPTIONS
 
 -k::
 --keep::
-	Pass `-k` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
+	Pass `-k` flag to `git mailinfo` (see linkgit:git-mailinfo[1]).
 
 --keep-non-patch::
-	Pass `-b` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
+	Pass `-b` flag to `git mailinfo` (see linkgit:git-mailinfo[1]).
 
 --[no-]keep-cr::
-	With `--keep-cr`, call 'git mailsplit' (see linkgit:git-mailsplit[1])
+	With `--keep-cr`, call `git mailsplit` (see linkgit:git-mailsplit[1])
 	with the same option, to prevent it from stripping CR at the end of
 	lines. `am.keepcr` configuration variable can be used to specify the
 	default behaviour.  `--no-keep-cr` is useful to override `am.keepcr`.
@@ -61,7 +61,7 @@ OPTIONS
 
 -m::
 --message-id::
-	Pass the `-m` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]),
+	Pass the `-m` flag to `git mailinfo` (see linkgit:git-mailinfo[1]),
 	so that the Message-ID header is added to the commit message.
 	The `am.messageid` configuration variable can be used to specify
 	the default behaviour.
@@ -76,7 +76,7 @@ OPTIONS
 
 -u::
 --utf8::
-	Pass `-u` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
+	Pass `-u` flag to `git mailinfo` (see linkgit:git-mailinfo[1]).
 	The proposed commit log message taken from the e-mail
 	is re-coded into UTF-8 encoding (configuration variable
 	`i18n.commitEncoding` can be used to specify project's
@@ -86,7 +86,7 @@ This was optional in prior versions of git, but now it is the
 default.   You can use `--no-utf8` to override this.
 
 --no-utf8::
-	Pass `-n` flag to 'git mailinfo' (see
+	Pass `-n` flag to `git mailinfo` (see
 	linkgit:git-mailinfo[1]).
 
 -3::
@@ -97,7 +97,7 @@ default.   You can use `--no-utf8` to override this.
 	it is supposed to apply to and we have those blobs
 	available locally. `--no-3way` can be used to override
 	am.threeWay configuration variable. For more information,
-	see am.threeWay in linkgit:git-config[1].
+	see `am.threeWay` in linkgit:git-config[1].
 
 --rerere-autoupdate::
 --no-rerere-autoupdate::
@@ -113,7 +113,7 @@ default.   You can use `--no-utf8` to override this.
 --exclude=<path>::
 --include=<path>::
 --reject::
-	These flags are passed to the 'git apply' (see linkgit:git-apply[1])
+	These flags are passed to the `git apply` (see linkgit:git-apply[1])
 	program that applies
 	the patch.
 
@@ -170,7 +170,7 @@ default.   You can use `--no-utf8` to override this.
 	to the screen before exiting.  This overrides the
 	standard message informing you to use `--continue`
 	or `--skip` to handle the failure.  This is solely
-	for internal use between 'git rebase' and 'git am'.
+	for internal use between `git rebase` and `git am`.
 
 --abort::
 	Restore the original branch and abort the patching operation.
@@ -231,7 +231,7 @@ names.
 
 Before any patches are applied, `ORIG_HEAD` is set to the tip of the
 current branch.  This is useful if you have problems with multiple
-commits, like running 'git am' on the wrong branch or an error in the
+commits, like running `git am` on the wrong branch or an error in the
 commits that is more easily fixed by changing the mailbox (e.g.
 errors in the "From:" lines).
 
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index f1c8098c0b..a836021d5e 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -51,7 +51,7 @@ OPTIONS
 
 --summary::
 	Instead of applying the patch, output a condensed
-	summary of information obtained from git diff extended
+	summary of information obtained from `git diff` extended
 	headers, such as creations, renames and mode changes.
 	Turns off "apply".
 
@@ -92,7 +92,7 @@ OPTIONS
 	with the `--reject` and the `--cached` options.
 
 --build-fake-ancestor=<file>::
-	Newer 'git diff' output has embedded 'index information'
+	Newer `git diff` output has embedded 'index information'
 	for each blob to help identify the original version that
 	the patch applies to.  When this flag is given, and if
 	the original versions of the blobs are available locally,
@@ -106,7 +106,7 @@ the information is read from the current index instead.
 	Apply the patch in reverse.
 
 --reject::
-	For atomicity, 'git apply' by default fails the whole patch and
+	For atomicity, `git apply` by default fails the whole patch and
 	does not touch the working tree when some of the hunks
 	do not apply.  This option makes it apply
 	the parts of the patch that are applicable, and leave the
@@ -133,7 +133,7 @@ linkgit:git-config[1]).
 	ever ignored.
 
 --unidiff-zero::
-	By default, 'git apply' expects that the patch being
+	By default, `git apply` expects that the patch being
 	applied is a unified diff with at least one line of context.
 	This provides good safety measures, but breaks down when
 	applying a diff generated with `--unified=0`. To bypass these
@@ -144,7 +144,7 @@ discouraged.
 
 --apply::
 	If you use any of the options marked "Turns off
-	'apply'" above, 'git apply' reads and outputs the
+	'apply'" above, `git apply` reads and outputs the
 	requested information without actually applying the
 	patch.  Give this flag after those flags to also apply
 	the patch.
@@ -243,7 +243,7 @@ running `git apply --directory=modules/git-gui`.
 --unsafe-paths::
 	By default, a patch that affects outside the working area
 	(either a Git controlled working tree, or the current working
-	directory when "git apply" is used as a replacement of GNU
+	directory when `git apply` is used as a replacement of GNU
 	patch) is rejected as a mistake (or a mischief).
 +
 When `git apply` is used as a "better GNU patch", the user can pass
@@ -263,7 +263,7 @@ apply.whitespace::
 
 SUBMODULES
 ----------
-If the patch contains any changes to submodules then 'git apply'
+If the patch contains any changes to submodules then `git apply`
 treats these changes as follows.
 
 If `--index` is specified (explicitly or implicitly), then the submodule
diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt
index 6e2dec5ef1..b5c9e500ca 100644
--- a/Documentation/git-archimport.txt
+++ b/Documentation/git-archimport.txt
@@ -30,17 +30,17 @@ branches that have different roots, it will refuse to run. In that case,
 edit your <archive/branch> parameters to define clearly the scope of the
 import.
 
-'git archimport' uses `tla` extensively in the background to access the
+`git archimport` uses `tla` extensively in the background to access the
 Arch repository.
 Make sure you have a recent version of `tla` available in the path. `tla` must
-know about the repositories you pass to 'git archimport'.
+know about the repositories you pass to `git archimport`.
 
-For the initial import, 'git archimport' expects to find itself in an empty
+For the initial import, `git archimport` expects to find itself in an empty
 directory. To follow the development of a project that uses Arch, rerun
-'git archimport' with the same parameters as the initial import to perform
+`git archimport` with the same parameters as the initial import to perform
 incremental imports.
 
-While 'git archimport' will try to create sensible branch names for the
+While `git archimport` will try to create sensible branch names for the
 archives that it imports, it is also possible to specify Git branch names
 manually.  To do so, write a Git branch name after each <archive/branch>
 parameter, separated by a colon.  This way, you can shorten the Arch
@@ -85,7 +85,7 @@ OPTIONS
 
 -o::
 	Use this for compatibility with old-style branch names used by
-	earlier versions of 'git archimport'.  Old-style branch names
+	earlier versions of `git archimport`.  Old-style branch names
 	were category{litdd}branch, whereas new-style branch names are
 	archive,category{litdd}branch{litdd}version.  In both cases, names given
 	on the command-line will override the automatically-generated
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 0af18c9df3..4bd6299046 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -21,13 +21,13 @@ structure for the named tree, and writes it out to the standard
 output.  If <prefix> is specified it is
 prepended to the filenames in the archive.
 
-'git archive' behaves differently when given a tree ID versus when
+`git archive` behaves differently when given a tree ID versus when
 given a commit ID or tag ID.  In the first case the current time is
 used as the modification time of each file in the archive.  In the latter
 case the commit time as recorded in the referenced commit object is
 used instead.  Additionally the commit ID is stored in a global
 extended pax header if the tar format is used; it can be extracted
-using 'git get-tar-commit-id'. In ZIP files it is stored as a file
+using `git get-tar-commit-id`. In ZIP files it is stored as a file
 comment.
 
 OPTIONS
@@ -78,7 +78,7 @@ OPTIONS
 
 --exec=<git-upload-archive>::
 	Used with `--remote` to specify the path to the
-	'git-upload-archive' on the remote side.
+	`git-upload-archive` on the remote side.
 
 <tree-ish>::
 	The tree or commit to produce an archive for.
diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt
index 1276424d65..b919b3ea42 100644
--- a/Documentation/git-bisect-lk2009.txt
+++ b/Documentation/git-bisect-lk2009.txt
@@ -7,16 +7,16 @@ Fighting regressions with git bisect
 Abstract
 --------
 
-"git bisect" enables software users and developers to easily find the
+`git bisect` enables software users and developers to easily find the
 commit that introduced a regression. We show why it is important to
-have good tools to fight regressions. We describe how "git bisect"
+have good tools to fight regressions. We describe how `git bisect`
 works from the outside and the algorithms it uses inside. Then we
-explain how to take advantage of "git bisect" to improve current
-practices. And we discuss how "git bisect" could improve in the
+explain how to take advantage of `git bisect` to improve current
+practices. And we discuss how `git bisect` could improve in the
 future.
 
 
-Introduction to "git bisect"
+Introduction to `git bisect`
 ----------------------------
 
 Git is a Distributed Version Control system (DVCS) created by Linus
@@ -36,14 +36,14 @@ properly fix a problem when you only need to check a very small set of
 changes, than when you don't know where look in the first place.
 
 So to help people find commits that introduce a "bad" behavior, the
-"git bisect" set of commands was invented. And it follows of course
-that in "git bisect" parlance, commits where the "interesting
+`git bisect` set of commands was invented. And it follows of course
+that in `git bisect` parlance, commits where the "interesting
 behavior" is present are called "bad" commits, while other commits are
 called "good" commits. And a commit that introduce the behavior we are
 interested in is called a "first bad commit". Note that there could be
 more than one "first bad commit" in the commit space we are searching.
 
-So "git bisect" is designed to help find a "first bad commit". And to
+So `git bisect` is designed to help find a "first bad commit". And to
 be as efficient as possible, it tries to perform a binary search.
 
 
@@ -133,7 +133,7 @@ time. But this is not the end of the fight yet, as of course it
 continues after the release.
 
 And then this is what Ingo Molnar (a well known Linux kernel
-developer) says about his use of git bisect:
+developer) says about his use of `git bisect`:
 
 _____________
 I most actively use it during the merge window (when a lot of trees
@@ -152,7 +152,7 @@ Other tools to fight regressions
 
 So what are the tools used to fight regressions? They are nearly the
 same as those used to fight regular bugs. The only specific tools are
-test suites and tools similar as "git bisect".
+test suites and tools similar as `git bisect`.
 
 Test suites are very nice. But when they are used alone, they are
 supposed to be used so that all the tests are checked after each
@@ -180,17 +180,17 @@ emulate a bisection process or you will perhaps bluntly test each
 commit backward starting from the "bad" commit you have which may be
 very wasteful.
 
-"git bisect" overview
+`git bisect` overview
 ---------------------
 
 Starting a bisection
 ~~~~~~~~~~~~~~~~~~~~
 
-The first "git bisect" subcommand to use is "git bisect start" to
+The first `git bisect` subcommand to use is `git bisect start` to
 start the search. Then bounds must be set to limit the commit
 space. This is done usually by giving one "bad" and at least one
-"good" commit. They can be passed in the initial call to "git bisect
-start" like this:
+"good" commit. They can be passed in the initial call to `git bisect
+start` like this:
 
 -------------
 $ git bisect start [BAD [GOOD...]]
@@ -211,7 +211,7 @@ $ git bisect good [COMMIT...]
 where BAD, GOOD and COMMIT are all names that can be resolved to a
 commit.
 
-Then "git bisect" will checkout a commit of its choosing and ask the
+Then `git bisect` will checkout a commit of its choosing and ask the
 user to test it, like this:
 
 -------------
@@ -224,8 +224,8 @@ Note that the example that we will use is really a toy example, we
 will be looking for the first commit that has a version like
 "2.6.26-something", that is the commit that has a "SUBLEVEL = 26" line
 in the top level Makefile. This is a toy example because there are
-better ways to find this commit with Git than using "git bisect" (for
-example "git blame" or "git log -S<string>").
+better ways to find this commit with Git than using `git bisect` (for
+example `git blame` or `git log -S<string>`).
 
 Driving a bisection manually
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -236,7 +236,7 @@ script or a command.
 
 If the user is driving it, then at each step of the search, the user
 will have to test the current commit and say if it is "good" or "bad"
-using the "git bisect good" or "git bisect bad" commands respectively
+using the `git bisect good` or `git bisect bad` commands respectively
 that have been described above. For example:
 
 -------------
@@ -245,7 +245,7 @@ Bisecting: 5480 revisions left to test after this (roughly 13 steps)
 [66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm
 -------------
 
-And after a few more steps like that, "git bisect" will eventually
+And after a few more steps like that, `git bisect` will eventually
 find a first bad commit:
 
 -------------
@@ -287,7 +287,7 @@ index 5cf8258..4492984 100644
  # *DOCUMENTATION*
 -------------
 
-And when we are finished we can use "git bisect reset" to go back to
+And when we are finished we can use `git bisect reset` to go back to
 the branch we were in before we started bisecting:
 
 -------------
@@ -300,10 +300,10 @@ Switched to branch 'master'
 Driving a bisection automatically
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The other way to drive the bisection process is to tell "git bisect"
+The other way to drive the bisection process is to tell `git bisect`
 to launch a script or command at each bisection step to know if the
-current commit is "good" or "bad". To do that, we use the "git bisect
-run" command. For example:
+current commit is "good" or "bad". To do that, we use the `git bisect
+run` command. For example:
 
 -------------
 $ git bisect start v2.6.27 v2.6.25
@@ -336,19 +336,19 @@ bisect run success
 -------------
 
 In this example, we passed "grep '^SUBLEVEL = 25' Makefile" as
-parameter to "git bisect run". This means that at each step, the grep
+parameter to `git bisect run`. This means that at each step, the grep
 command we passed will be launched. And if it exits with code 0 (that
-means success) then git bisect will mark the current state as
+means success) then `git bisect` will mark the current state as
 "good". If it exits with code 1 (or any code between 1 and 127
 included, except the special code 125), then the current state will be
 marked as "bad".
 
-Exit code between 128 and 255 are special to "git bisect run". They
+Exit code between 128 and 255 are special to `git bisect run`. They
 make it stop immediately the bisection process. This is useful for
 example if the command passed takes too long to complete, because you
 can kill it with a signal and it will stop the bisection process.
 
-It can also be useful in scripts passed to "git bisect run" to "exit
+It can also be useful in scripts passed to `git bisect run` to "exit
 255" if some very abnormal situation is detected.
 
 Avoiding untestable commits
@@ -357,15 +357,15 @@ Avoiding untestable commits
 Sometimes it happens that the current state cannot be tested, for
 example if it does not compile because there was a bug preventing it
 at that time. This is what the special exit code 125 is for. It tells
-"git bisect run" that the current commit should be marked as
+`git bisect run` that the current commit should be marked as
 untestable and that another one should be chosen and checked out.
 
-If the bisection process is driven manually, you can use "git bisect
-skip" to do the same thing. (In fact the special exit code 125 makes
-"git bisect run" use "git bisect skip" in the background.)
+If the bisection process is driven manually, you can use `git bisect
+skip` to do the same thing. (In fact the special exit code 125 makes
+`git bisect run` use `git bisect skip` in the background.)
 
 Or if you want more control, you can inspect the current state using
-for example "git bisect visualize". It will launch gitk (or "git log"
+for example `git bisect visualize`. It will launch gitk (or `git log`
 if the `DISPLAY` environment variable is not set) to help you find a
 better bisection point.
 
@@ -374,7 +374,7 @@ happen that the regression you are looking for has been introduced by
 one of these untestable commits. In this case it's not possible to
 tell for sure which commit introduced the regression.
 
-So if you used "git bisect skip" (or the run script exited with
+So if you used `git bisect skip` (or the run script exited with
 special code 125) you could get a result like this:
 
 -------------
@@ -415,7 +415,7 @@ best bisection commit to test at each step is not so simple. Anyway
 Linus found and implemented a "truly stupid" algorithm, later improved
 by Junio Hamano, that works quite well.
 
-So the algorithm used by "git bisect" to find the best bisection
+So the algorithm used by `git bisect` to find the best bisection
 commit when there are no skipped commits is the following:
 
 1) keep only the commits that:
@@ -530,7 +530,7 @@ Bisection algorithm debugging
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 For any commit graph, you can see the number associated with each
-commit using "git rev-list --bisect-all".
+commit using `git rev-list --bisect-all`.
 
 For example, for the above graph, a command like:
 
@@ -658,7 +658,7 @@ A-B-C-D-E-F         O
             4 3 2 1
 -------------
 
-but with the algorithm used by git bisect we get:
+but with the algorithm used by `git bisect` we get:
 
 -------------
             7 7 6 5
@@ -682,7 +682,7 @@ initially supposed.
 Skip algorithm
 ~~~~~~~~~~~~~~
 
-When some commits have been skipped (using "git bisect skip"), then
+When some commits have been skipped (using `git bisect skip`), then
 the bisection algorithm is the same for step 1) to 3). But then we use
 roughly the following steps:
 
@@ -709,7 +709,7 @@ Skip algorithm discussed
 
 After step 7) (in the skip algorithm), we could check if the second
 commit has been skipped and return it if it is not the case. And in
-fact that was the algorithm we used from when "git bisect skip" was
+fact that was the algorithm we used from when `git bisect skip` was
 developed in Git version 1.5.4 (released on February 1st 2008) until
 Git version 1.6.4 (released July 29th 2009).
 
@@ -852,10 +852,10 @@ usual after this step.
 Best bisecting practices
 ------------------------
 
-Using test suites and git bisect together
+Using test suites and `git bisect` together
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If you both have a test suite and use git bisect, then it becomes less
+If you both have a test suite and use `git bisect`, then it becomes less
 important to check that all tests pass after each commit. Though of
 course it is probably a good idea to have some checks to avoid
 breaking too many things because it could make bisecting other bugs
@@ -864,7 +864,7 @@ more difficult.
 You can focus your efforts to check at a few points (for example rc
 and beta releases) that all the T test cases pass for all the N
 configurations. And when some tests don't pass you can use "git
-bisect" (or better "git bisect run"). So you should perform roughly:
+bisect" (or better `git bisect run`). So you should perform roughly:
 
 -------------
 c * N * T + b * M * log2(M) tests
@@ -879,11 +879,11 @@ you would test everything after each commit.
 This means that test suites are good to prevent some bugs from being
 committed and they are also quite good to tell you that you have some
 bugs. But they are not so good to tell you where some bugs have been
-introduced. To tell you that efficiently, git bisect is needed.
+introduced. To tell you that efficiently, `git bisect` is needed.
 
 The other nice thing with test suites, is that when you have one, you
 already know how to test for bad behavior. So you can use this
-knowledge to create a new test case for "git bisect" when it appears
+knowledge to create a new test case for `git bisect` when it appears
 that there is a regression. So it will be easier to bisect the bug and
 fix it. And then you can add the test case you just created to your
 test suite.
@@ -893,7 +893,7 @@ subject to a virtuous circle:
 
 more tests => easier to create tests => easier to bisect => more tests
 
-So test suites and "git bisect" are complementary tools that are very
+So test suites and `git bisect` are complementary tools that are very
 powerful and efficient when used together.
 
 Bisecting build failures
@@ -907,7 +907,7 @@ $ git bisect start BAD GOOD
 $ git bisect run make
 -------------
 
-Passing sh -c "some commands" to "git bisect run"
+Passing sh -c "some commands" to `git bisect run`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 For example:
@@ -925,7 +925,7 @@ Finding performance regressions
 Here is an example script that comes slightly modified from a real
 world script used by Junio Hamano <<4>>.
 
-This script can be passed to "git bisect run" to find the commit that
+This script can be passed to `git bisect run` to find the commit that
 introduced a performance regression:
 
 -------------
@@ -969,7 +969,7 @@ It is also a good idea when using any VCS to have only one small
 logical change in each commit.
 
 The smaller the changes in your commit, the most effective "git
-bisect" will be. And you will probably need "git bisect" less in the
+bisect" will be. And you will probably need `git bisect` less in the
 first place, as small changes are easier to review even if they are
 only reviewed by the committer.
 
@@ -996,7 +996,7 @@ misleading to know the first bad commit if it happens to be such a
 merge, because people might think that the bug comes from bad conflict
 resolution when it comes from a semantic change in one branch.
 
-Anyway "git rebase" can be used to linearize history. This can be used
+Anyway `git rebase` can be used to linearize history. This can be used
 either to avoid merging in the first place. Or it can be used to
 bisect on a linear history instead of the non linear one, as this
 should give more information in case of a semantic change in one
@@ -1016,7 +1016,7 @@ A special work-flow to process regressions can give great results.
 Here is an example of a work-flow used by Andreas Ericsson:
 
 * write, in the test suite, a test script that exposes the regression
-* use "git bisect run" to find the commit that introduced it
+* use `git bisect run` to find the commit that introduced it
 * fix the bug that is often made obvious by the previous step
 * commit both the fix and the test script (and if needed more tests)
 
@@ -1034,7 +1034,7 @@ due to how we now feel about writing tests).
 _____________
 
 Clearly this work-flow uses the virtuous circle between test suites
-and "git bisect". In fact it makes it the standard procedure to deal
+and `git bisect`. In fact it makes it the standard procedure to deal
 with regression.
 
 In other messages Andreas says that they also use the "best practices"
@@ -1048,7 +1048,7 @@ is making bisecting easier, more useful and standard.
 Involving QA people and if possible end users
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-One nice about "git bisect" is that it is not only a developer
+One nice about `git bisect` is that it is not only a developer
 tool. It can effectively be used by QA people or even end users (if
 they have access to the source code or if they can get access to all
 the builds).
@@ -1091,7 +1091,7 @@ Here is what Ingo Molnar says about that <<7>>:
 
 _____________
 i have a fully automated bootup-hang bisection script. It is based on
-"git-bisect run". I run the script, it builds and boots kernels fully
+`git-bisect run`. I run the script, it builds and boots kernels fully
 automatically, and when the bootup fails (the script notices that via
 the serial log, which it continuously watches - or via a timeout, if
 the system does not come up within 10 minutes it's a "bad" kernel),
@@ -1100,28 +1100,28 @@ box. (yeah, i should make use of a managed power outlet to 100%
 automate it)
 _____________
 
-Combining test suites, git bisect and other systems together
+Combining test suites, `git bisect` and other systems together
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-We have seen that test suites and git bisect are very powerful when
+We have seen that test suites and `git bisect` are very powerful when
 used together. It can be even more powerful if you can combine them
 with other systems.
 
 For example some test suites could be run automatically at night with
 some unusual (or even random) configurations. And if a regression is
-found by a test suite, then "git bisect" can be automatically
+found by a test suite, then `git bisect` can be automatically
 launched, and its result can be emailed to the author of the first bad
-commit found by "git bisect", and perhaps other people too. And a new
+commit found by `git bisect`, and perhaps other people too. And a new
 entry in the bug tracking system could be automatically created too.
 
 
 The future of bisecting
 -----------------------
 
-"git replace"
+`git replace`
 ~~~~~~~~~~~~~
 
-We saw earlier that "git bisect skip" is now using a PRNG to try to
+We saw earlier that `git bisect skip` is now using a PRNG to try to
 avoid areas in the commit graph where commits are untestable. The
 problem is that sometimes the first bad commit will be in an
 untestable area.
@@ -1177,26 +1177,26 @@ For example:
 $ git bisect start Z' Y
 -------------
 
-If you are using "git bisect run", you can use the same manual fix up
-as above, and then start another "git bisect run" in the special
-branch. Or as the "git bisect" man page says, the script passed to
-"git bisect run" can apply a patch before it compiles and test the
+If you are using `git bisect run`, you can use the same manual fix up
+as above, and then start another `git bisect run` in the special
+branch. Or as the `git bisect` man page says, the script passed to
+`git bisect run` can apply a patch before it compiles and test the
 software <<8>>. The patch should turn a current untestable commits
 into a testable one. So the testing will result in "good" or "bad" and
-"git bisect" will be able to find the first bad commit. And the script
+`git bisect` will be able to find the first bad commit. And the script
 should not forget to remove the patch once the testing is done before
 exiting from the script.
 
-(Note that instead of a patch you can use "git cherry-pick BFC" to
-apply the fix, and in this case you should use "git reset --hard
-HEAD^" to revert the cherry-pick after testing and before returning
+(Note that instead of a patch you can use `git cherry-pick BFC` to
+apply the fix, and in this case you should use `git reset --hard
+HEAD` to revert the cherry-pick after testing and before returning
 from the script.)
 
 But the above ways to work around untestable areas are a little bit
 clunky. Using special branches is nice because these branches can be
 shared by developers like usual branches, but the risk is that people
-will get many such branches. And it disrupts the normal "git bisect"
-work-flow. So, if you want to use "git bisect run" completely
+will get many such branches. And it disrupts the normal `git bisect`
+work-flow. So, if you want to use `git bisect run` completely
 automatically, you have to add special code in your script to restart
 bisection in the special branches.
 
@@ -1217,13 +1217,13 @@ With the example above that would give:
 ...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z
 -------------
 
-That's why the "git replace" command was created. Technically it
+That's why the `git replace` command was created. Technically it
 stores replacements "refs" in the "refs/replace/" hierarchy. These
 "refs" are like branches (that are stored in "refs/heads/") or tags
 (that are stored in "refs/tags"), and that means that they can
 automatically be shared like branches or tags among developers.
 
-"git replace" is a very powerful mechanism. It can be used to fix
+`git replace` is a very powerful mechanism. It can be used to fix
 commits in already released history, for example to change the commit
 message or the author. And it can also be used instead of git "grafts"
 to link a repository with another old repository.
@@ -1232,7 +1232,7 @@ In fact it's this last feature that "sold" it to the Git community, so
 it is now in the `master` branch of Git's Git repository and it should
 be released in Git 1.6.5 in October or November 2009.
 
-One problem with "git replace" is that currently it stores all the
+One problem with `git replace` is that currently it stores all the
 replacements refs in "refs/replace/", but it would be perhaps better
 if the replacement refs that are useful only for bisecting would be in
 "refs/replace/bisect/". This way the replacement refs could be used
@@ -1242,7 +1242,7 @@ be used nearly all the time.
 Bisecting sporadic bugs
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-Another possible improvement to "git bisect" would be to optionally
+Another possible improvement to `git bisect` would be to optionally
 add some redundancy to the tests performed so that it would be more
 reliable when tracking sporadic bugs.
 
@@ -1250,7 +1250,7 @@ This has been requested by some kernel developers because some bugs
 called sporadic bugs do not appear in all the kernel builds because
 they are very dependent on the compiler output.
 
-The idea is that every 3 test for example, "git bisect" could ask the
+The idea is that every 3 test for example, `git bisect` could ask the
 user to test a commit that has already been found to be "good" or
 "bad" (because one of its descendants or one of its ancestors has been
 found to be "good" or "bad" respectively). If it happens that a commit
@@ -1264,7 +1264,7 @@ on Github that does something like that using Bayesian Search Theory
 <<9>>:
 
 _____________
-BBChop is like 'git bisect' (or equivalent), but works when your bug
+BBChop is like `git bisect` (or equivalent), but works when your bug
 is intermittent. That is, it works in the presence of false negatives
 (when a version happens to work this time even though it contains the
 bug). It assumes that there are no false positives (in principle, the
@@ -1283,12 +1283,12 @@ other tools, especially test suites, that are generally used to fight
 regressions. But it might be needed to change some work-flows and
 (bad) habits to get the most out of it.
 
-Some improvements to the algorithms inside "git bisect" are possible
+Some improvements to the algorithms inside `git bisect` are possible
 and some new features could help in some cases, but overall "git
 bisect" works already very well, is used a lot, and is already very
 useful. To back up that last claim, let's give the final word to Ingo
 Molnar when he was asked by the author how much time does he think
-"git bisect" saves him when he uses it:
+`git bisect` saves him when he uses it:
 
 _____________
 a _lot_.
@@ -1307,7 +1307,7 @@ manual help or when bisecting multiple, overlapping bugs, it's rarely
 more than an hour.
 
 In fact it's invaluable because there are bugs i would never even
-_try_ to debug if it wasn't for git bisect. In the past there were bug
+_try_ to debug if it wasn't for `git bisect`. In the past there were bug
 patterns that were immediately hopeless for me to debug - at best i
 could send the crash/bug signature to lkml and hope that someone else
 can think of something.
@@ -1316,7 +1316,7 @@ And even if a bisection fails today it tells us something valuable
 about the bug: that it's non-deterministic - timing or kernel image
 layout dependent.
 
-So git bisect is unconditional goodness - and feel free to quote that
+So `git bisect` is unconditional goodness - and feel free to quote that
 ;-)
 _____________
 
@@ -1325,16 +1325,16 @@ Acknowledgments
 
 Many thanks to Junio Hamano for his help in reviewing this paper, for
 reviewing the patches I sent to the Git mailing list, for discussing
-some ideas and helping me improve them, for improving "git bisect" a
+some ideas and helping me improve them, for improving `git bisect` a
 lot and for his awesome work in maintaining and developing Git.
 
 Many thanks to Ingo Molnar for giving me very useful information that
 appears in this paper, for commenting on this paper, for his
-suggestions to improve "git bisect" and for evangelizing "git bisect"
+suggestions to improve `git bisect` and for evangelizing `git bisect`
 on the linux kernel mailing lists.
 
 Many thanks to Linus Torvalds for inventing, developing and
-evangelizing "git bisect", Git and Linux.
+evangelizing `git bisect`, Git and Linux.
 
 Many thanks to the many other great people who helped one way or
 another when I worked on Git, especially to Andreas Ericsson, Johannes
@@ -1351,7 +1351,7 @@ References
 - [[[2]]] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html['Code Conventions for the Java Programming Language'. Sun Microsystems.]
 - [[[3]]] https://en.wikipedia.org/wiki/Software_maintenance['Software maintenance'. Wikipedia.]
 - [[[4]]] https://lore.kernel.org/git/7vps5xsbwp.fsf_-_@assigned-by-dhcp.cox.net/[Junio C Hamano. 'Automated bisect success story'.]
-- [[[5]]] https://lwn.net/Articles/317154/[Christian Couder. 'Fully automated bisecting with "git bisect run"'. LWN.net.]
+- [[[5]]] https://lwn.net/Articles/317154/[Christian Couder. 'Fully automated bisecting with `git bisect run`'. LWN.net.]
 - [[[6]]] https://lwn.net/Articles/277872/[Jonathan Corbet. 'Bisection divides users and developers'. LWN.net.]
 - [[[7]]] https://lore.kernel.org/lkml/20071207113734.GA14598@elte.hu/[Ingo Molnar. 'Re: BUG 2.6.23-rc3 can't see sd partitions on Alpha'. Linux-kernel mailing list.]
 - [[[8]]] https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html[Junio C Hamano and the git-list. 'git-bisect(1) Manual Page'. Linux Kernel Archives.]
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index ff50c66e29..d59422636b 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -9,25 +9,25 @@ git-bisect - Use binary search to find the commit that introduced a bug
 SYNOPSIS
 --------
 [verse]
-'git bisect' <subcommand> <options>
+`git bisect` <subcommand> <options>
 
 DESCRIPTION
 -----------
 The command takes various subcommands, and different options depending
 on the subcommand:
 
- git bisect start [--term-{new,bad}=<term> --term-{old,good}=<term>]
-		  [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<paths>...]
- git bisect (bad|new|<term-new>) [<rev>]
- git bisect (good|old|<term-old>) [<rev>...]
- git bisect terms [--term-good | --term-bad]
- git bisect skip [(<rev>|<range>)...]
- git bisect reset [<commit>]
- git bisect (visualize|view)
- git bisect replay <logfile>
- git bisect log
- git bisect run <cmd>...
- git bisect help
+ `git bisect` start [--term-{new,bad}=<term> --term-{old,good}=<term>]
+ 	    	  [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<paths>...]
+ `git bisect` (bad|new|<term-new>) [<rev>]
+ `git bisect` (good|old|<term-old>) [<rev>...]
+ `git bisect` terms [--term-good | --term-bad]
+ `git bisect` skip [(<rev>|<range>)...]
+ `git bisect` reset [<commit>]
+ `git bisect` (visualize|view)
+ `git bisect` replay <logfile>
+ `git bisect` log
+ `git bisect` run <cmd>...
+ `git bisect` help
 
 This command uses a binary search algorithm to find which commit in
 your project's history introduced a bug. You use it by first telling
@@ -196,7 +196,7 @@ of `git bisect good` and `git bisect bad` to mark commits.
 Bisect visualize/view
 ~~~~~~~~~~~~~~~~~~~~~
 
-To see the currently remaining suspects in 'gitk', issue the following
+To see the currently remaining suspects in `gitk`, issue the following
 command during the bisection process (the subcommand `view` can be used
 as an alternative to `visualize`):
 
@@ -204,7 +204,7 @@ as an alternative to `visualize`):
 $ git bisect visualize
 ------------
 
-If the `DISPLAY` environment variable is not set, 'git log' is used
+If the `DISPLAY` environment variable is not set, `git log` is used
 instead.  You can also give command-line options such as `-p` and
 `--stat`.
 
@@ -344,7 +344,7 @@ header file, or "revision that does not have this commit needs this
 patch applied to work around another problem this bisection is not
 interested in") applied to the revision being tested.
 
-To cope with such a situation, after the inner 'git bisect' finds the
+To cope with such a situation, after the inner `git bisect` finds the
 next revision to test, the script can apply the patch
 before compiling, run the real test, and afterwards decide if the
 revision (possibly with the needed patch) passed the test and then
@@ -475,9 +475,9 @@ $ git bisect run sh -c '
 $ git bisect reset                   # quit the bisect session
 ------------
 +
-In this case, when 'git bisect run' finishes, bisect/bad will refer to a commit that
+In this case, when `git bisect run` finishes, bisect/bad will refer to a commit that
 has at least one parent whose reachable graph is fully traversable in the sense
-required by 'git pack objects'.
+required by `git pack objects`.
 
 * Look for a fix instead of a regression in the code
 +
@@ -502,7 +502,7 @@ help` or `git bisect -h` to get a long usage description.
 
 SEE ALSO
 --------
-link:git-bisect-lk2009.html[Fighting regressions with git bisect],
+link:git-bisect-lk2009.html[Fighting regressions with `git bisect`],
 linkgit:git-blame[1].
 
 GIT
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 3bf5d5d8b4..aa1b5d56d3 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -8,7 +8,7 @@ git-blame - Show what revision and author last modified each line of a file
 SYNOPSIS
 --------
 [verse]
-'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
+`git blame` [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
 	    [-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
 	    [--ignore-rev <rev>] [--ignore-revs-file <file>]
 	    [--progress] [--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>..<rev>]
@@ -30,7 +30,7 @@ lines that were copied and pasted from another file, etc., see the
 `-C` and `-M` options.
 
 The report does not tell you anything about lines which have been deleted or
-replaced; you need to use a tool such as 'git diff' or the "pickaxe"
+replaced; you need to use a tool such as `git diff` or the "pickaxe"
 interface briefly mentioned in the following paragraph.
 
 Apart from supporting file annotation, Git also supports searching the
@@ -59,7 +59,7 @@ include::blame-options.txt[]
 	file (see `-M`).  The first number listed is the score.
 	This is the number of alphanumeric characters detected
 	as having been moved between or within files.  This must be above
-	a certain threshold for 'git blame' to consider those lines
+	a certain threshold for `git blame` to consider those lines
 	of code to have been moved.
 
 -f::
@@ -136,7 +136,7 @@ usage like:
 SPECIFYING RANGES
 -----------------
 
-Unlike 'git blame' and 'git annotate' in older versions of git, the extent
+Unlike `git blame` and `git annotate` in older versions of git, the extent
 of the annotation can be limited to both line ranges and revision
 ranges. The `-L` option, which limits annotation to a range of lines, may be
 specified multiple times.
@@ -157,7 +157,7 @@ which limits the annotation to the body of the `hello` subroutine.
 
 When you are not interested in changes older than version
 v2.6.18, or changes older than 3 weeks, you can use revision
-range specifiers  similar to 'git rev-list':
+range specifiers  similar to `git rev-list`:
 
 	git blame v2.6.18.. -- foo
 	git blame --since=3.weeks -- foo
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 8ea6e1e523..6f37f11b33 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -8,7 +8,7 @@ git-branch - List, create, or delete branches
 SYNOPSIS
 --------
 [verse]
-'git branch' [--color[=<when>] | --no-color] [--show-current]
+`git branch` [--color[=<when>] | --no-color] [--show-current]
 	[-v [--abbrev=<n> | --no-abbrev]]
 	[--column[=<options>] | --no-column] [--sort=<key>]
 	[--merged [<commit>]] [--no-merged [<commit>]]
@@ -16,13 +16,13 @@ SYNOPSIS
 	[--points-at <object>] [--format=<format>]
 	[(-r | --remotes) | (-a | --all)]
 	[--list] [<pattern>...]
-'git branch' [--track | --no-track] [-f] <branchname> [<start-point>]
-'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
-'git branch' --unset-upstream [<branchname>]
-'git branch' (-m | -M) [<oldbranch>] <newbranch>
-'git branch' (-c | -C) [<oldbranch>] <newbranch>
-'git branch' (-d | -D) [-r] <branchname>...
-'git branch' --edit-description [<branchname>]
+`git branch` [--track | --no-track] [-f] <branchname> [<start-point>]
+`git branch` (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
+`git branch` --unset-upstream [<branchname>]
+`git branch` (-m | -M) [<oldbranch>] <newbranch>
+`git branch` (-c | -C) [<oldbranch>] <newbranch>
+`git branch` (-d | -D) [-r] <branchname>...
+`git branch` --edit-description [<branchname>]
 
 DESCRIPTION
 -----------
@@ -60,12 +60,12 @@ can leave out at most one of `A` and `B`, in which case it defaults to
 `HEAD`.
 
 Note that this will create the new branch, but it will not switch the
-working tree to it; use "git switch <newbranch>" to switch to the
+working tree to it; use `git switch <newbranch>` to switch to the
 new branch.
 
 When a local branch is started off a remote-tracking branch, Git sets up the
 branch (specifically the `branch.<name>.remote` and `branch.<name>.merge`
-configuration entries) so that 'git pull' will appropriately merge from
+configuration entries) so that `git pull` will appropriately merge from
 the remote-tracking branch. This behavior may be changed via the global
 `branch.autoSetupMerge` configuration flag. That setting can be
 overridden by using the `--track` and `--no-track` options, and
@@ -87,7 +87,7 @@ has a reflog then the reflog will also be deleted.
 
 Use `-r` together with `-d` to delete remote-tracking branches. Note, that it
 only makes sense to delete remote-tracking branches if they no longer exist
-in the remote repository or if 'git fetch' was configured not to fetch
+in the remote repository or if `git fetch` was configured not to fetch
 them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a
 way to clean up all obsolete remote-tracking branches.
 
@@ -116,7 +116,7 @@ OPTIONS
 -f::
 --force::
 	Reset <branchname> to <startpoint>, even if <branchname> exists
-	already. Without `-f`, 'git branch' refuses to change an existing branch.
+	already. Without `-f`, `git branch` refuses to change an existing branch.
 	In combination with `-d` (or `--delete`), allow deleting the
 	branch irrespective of its merged status. In combination with
 	`-m` (or `--move`), allow renaming the branch even if the new
@@ -209,7 +209,7 @@ This option is only applicable in non-verbose mode.
 	When creating a new branch, set up `branch.<name>.remote` and
 	`branch.<name>.merge` configuration entries to mark the
 	start-point branch as "upstream" from the new branch. This
-	configuration will tell git to show the relationship between the
+	configuration will tell `git` to show the relationship between the
 	two branches in `git status` and `git branch -v`. Furthermore,
 	it directs `git pull` without arguments to pull from the
 	upstream when the new branch is checked out.
@@ -351,7 +351,7 @@ NOTES
 -----
 
 If you are creating a branch that you want to switch to immediately,
-it is easier to use the "git switch" command with its `-c` option to
+it is easier to use the `git switch` command with its `-c` option to
 do the same thing with a single command.
 
 The options `--contains`, `--no-contains`, `--merged` and `--no-merged`
diff --git a/Documentation/git-bugreport.txt b/Documentation/git-bugreport.txt
index 66e88c2e31..bb1355248e 100644
--- a/Documentation/git-bugreport.txt
+++ b/Documentation/git-bugreport.txt
@@ -25,7 +25,7 @@ The following information is requested from the user:
 
 The following information is captured automatically:
 
- - 'git version --build-options'
+ - `git version --build-options`
  - uname sysname, release, version, and machine strings
  - Compiler-specific info string
  - A list of enabled hooks
@@ -46,7 +46,7 @@ OPTIONS
 -s <format>::
 --suffix <format>::
 	Specify an alternate suffix for the bugreport name, to create a file
-	named 'git-bugreport-<formatted suffix>'. This should take the form of a
+	named `git-bugreport-<formatted suffix>`. This should take the form of a
 	strftime(3) format string; the current local time will be used.
 
 GIT
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 20da47cbd6..fb0ebe1257 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -9,11 +9,11 @@ git-bundle - Move objects and refs by archive
 SYNOPSIS
 --------
 [verse]
-'git bundle' create [-q | --quiet | --progress | --all-progress] [--all-progress-implied]
+`git bundle` create [-q | --quiet | --progress | --all-progress] [--all-progress-implied]
 		    [--version=<version>] <file> <git-rev-list-args>
-'git bundle' verify [-q | --quiet] <file>
-'git bundle' list-heads <file> [<refname>...]
-'git bundle' unbundle <file> [<refname>...]
+`git bundle` verify [-q | --quiet] <file>
+`git bundle` list-heads <file> [<refname>...]
+`git bundle` unbundle <file> [<refname>...]
 
 DESCRIPTION
 -----------
@@ -23,9 +23,9 @@ machine be replicated on another machine, but the two machines cannot
 be directly connected, and therefore the interactive Git protocols (git,
 ssh, http) cannot be used.
 
-The 'git bundle' command packages objects and references in an archive
+The `git bundle` command packages objects and references in an archive
 at the originating machine, which can then be imported into another
-repository using 'git fetch', 'git pull', or 'git clone',
+repository using `git fetch`, `git pull`, or `git clone`,
 after moving the archive by some means (e.g., by sneakernet).
 
 As no
@@ -40,7 +40,7 @@ OPTIONS
 create [options] <file> <git-rev-list-args>::
 	Used to create a bundle named 'file'.  This requires the
 	'<git-rev-list-args>' arguments to define the bundle contents.
-	'options' contains the options specific to the 'git bundle create'
+	'options' contains the options specific to the `git bundle create`
 	subcommand.
 
 verify <file>::
@@ -48,7 +48,7 @@ verify <file>::
 	cleanly to the current repository.  This includes checks on the
 	bundle format itself as well as checking that the prerequisite
 	commits exist and are fully linked in the current repository.
-	'git bundle' prints a list of missing commits, if any, and exits
+	`git bundle` prints a list of missing commits, if any, and exits
 	with a non-zero status.
 
 list-heads <file>::
@@ -57,15 +57,15 @@ list-heads <file>::
 	printed out.
 
 unbundle <file>::
-	Passes the objects in the bundle to 'git index-pack'
+	Passes the objects in the bundle to `git index-pack`
 	for storage in the repository, then prints the names of all
 	defined references. If a list of references is given, only
 	references matching those in the list are printed. This command is
-	really plumbing, intended to be called only by 'git fetch'.
+	really plumbing, intended to be called only by `git fetch`.
 
 <git-rev-list-args>::
-	A list of arguments, acceptable to 'git rev-parse' and
-	'git rev-list' (and containing a named ref, see SPECIFYING REFERENCES
+	A list of arguments, acceptable to `git rev-parse` and
+	`git rev-list` (and containing a named ref, see SPECIFYING REFERENCES
 	below), that specifies the specific objects and references
 	to transport.  For example, `master~10..master` causes the
 	current `master` reference to be packaged along with all objects
@@ -76,10 +76,10 @@ unbundle <file>::
 
 [<refname>...]::
 	A list of references used to limit the references reported as
-	available. This is principally of use to 'git fetch', which
+	available. This is principally of use to `git fetch`, which
 	expects to receive only those references asked for and not
-	necessarily everything in the pack (in this case, 'git bundle' acts
-	like 'git fetch-pack').
+	necessarily everything in the pack (in this case, `git bundle` acts
+	like `git fetch-pack`).
 
 --progress::
 	Progress status is reported on the standard error stream
@@ -117,8 +117,8 @@ unbundle <file>::
 SPECIFYING REFERENCES
 ---------------------
 
-'git bundle' will only package references that are shown by
-'git show-ref': this includes heads, tags, and remote heads.  References
+`git bundle` will only package references that are shown by
+`git show-ref`: this includes heads, tags, and remote heads.  References
 such as `master~1` cannot be packaged, but are perfectly suitable for
 defining the basis.  More than one reference may be packaged, and more
 than one basis can be specified.  The objects packaged are those not
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index 4eb0421b3f..3ac3d44fcb 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-file.txt
@@ -9,8 +9,8 @@ git-cat-file - Provide content or type and size information for repository objec
 SYNOPSIS
 --------
 [verse]
-'git cat-file' (-t [--allow-unknown-type]| -s [--allow-unknown-type]| -e | -p | <type> | --textconv | --filters ) [--path=<path>] <object>
-'git cat-file' (--batch[=<format>] | --batch-check[=<format>]) [ --textconv | --filters ] [--follow-symlinks]
+`git cat-file` (-t [--allow-unknown-type]| -s [--allow-unknown-type]| -e | -p | <type> | --textconv | --filters ) [--path=<path>] <object>
+`git cat-file` (--batch[=<format>] | --batch-check[=<format>]) [ --textconv | --filters ] [--follow-symlinks]
 
 DESCRIPTION
 -----------
@@ -134,7 +134,7 @@ one in the tree.
 This option cannot (currently) be used unless `--batch` or
 `--batch-check` is used.
 +
-For example, consider a git repository containing:
+For example, consider a `git` repository containing:
 +
 --
 	f: a file containing "hello\n"
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
index 84f41a8e82..0ac496700e 100644
--- a/Documentation/git-check-attr.txt
+++ b/Documentation/git-check-attr.txt
@@ -9,8 +9,8 @@ git-check-attr - Display gitattributes information
 SYNOPSIS
 --------
 [verse]
-'git check-attr' [-a | --all | <attr>...] [--] <pathname>...
-'git check-attr' --stdin [-z] [-a | --all | <attr>...]
+`git check-attr` [-a | --all | <attr>...] [--] <pathname>...
+`git check-attr` --stdin [-z] [-a | --all | <attr>...]
 
 DESCRIPTION
 -----------
diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt
index 0c3924a63d..56a4f655c8 100644
--- a/Documentation/git-check-ignore.txt
+++ b/Documentation/git-check-ignore.txt
@@ -9,8 +9,8 @@ git-check-ignore - Debug gitignore / exclude files
 SYNOPSIS
 --------
 [verse]
-'git check-ignore' [<options>] <pathname>...
-'git check-ignore' [<options>] --stdin
+`git check-ignore` [<options>] <pathname>...
+`git check-ignore` [<options>] --stdin
 
 DESCRIPTION
 -----------
diff --git a/Documentation/git-check-mailmap.txt b/Documentation/git-check-mailmap.txt
index 02f4418323..302049afe4 100644
--- a/Documentation/git-check-mailmap.txt
+++ b/Documentation/git-check-mailmap.txt
@@ -9,7 +9,7 @@ git-check-mailmap - Show canonical names and email addresses of contacts
 SYNOPSIS
 --------
 [verse]
-'git check-mailmap' [<options>] <contact>...
+`git check-mailmap` [<options>] <contact>...
 
 
 DESCRIPTION
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index f39622c0da..77beb46e98 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -8,10 +8,10 @@ git-check-ref-format - Ensures that a reference name is well formed
 SYNOPSIS
 --------
 [verse]
-'git check-ref-format' [--normalize]
+`git check-ref-format` [--normalize]
        [--[no-]allow-onelevel] [--refspec-pattern]
        <refname>
-'git check-ref-format' --branch <branchname-shorthand>
+`git check-ref-format` --branch <branchname-shorthand>
 
 DESCRIPTION
 -----------
@@ -73,7 +73,7 @@ reference name expressions (see linkgit:gitrevisions[7]):
 . A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
   value and store it in dstref" in fetch and push operations.
   It may also be used to select a specific object such as with
-  'git cat-file': "git cat-file blob v1.3.3:refs.c".
+  `git cat-file`: `git cat-file blob v1.3.3:refs.c`.
 
 . at-open-brace `@{` is used as a notation to access a reflog entry.
 
@@ -88,7 +88,7 @@ but it is explicitly forbidden at the beginning of a branch name).
 When run with `--branch` option in a repository, the input is first
 expanded for the ``previous checkout syntax''
 `@{-n}`.  For example, `@{-1}` is a way to refer the last thing that
-was checked out using "git switch" or "git checkout" operation.
+was checked out using `git switch` or `git checkout` operation.
 This option should be
 used by porcelains to accept this syntax anywhere a branch name is
 expected, so they can act as if you typed the branch name. As an
diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt
index b06d3ae3d9..6e49062ea3 100644
--- a/Documentation/git-checkout-index.txt
+++ b/Documentation/git-checkout-index.txt
@@ -9,7 +9,7 @@ git-checkout-index - Copy files from the index to the working tree
 SYNOPSIS
 --------
 [verse]
-'git checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
+`git checkout-index` [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
 		   [--stage=<number>|all]
 		   [--temp]
 		   [-z] [--stdin]
@@ -88,7 +88,7 @@ $ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
 which will force all existing `*.h` files to be replaced with their
 cached copies. If an empty command line implied "all", then this would
 force-refresh everything in the index, which was not the point.  But
-since 'git checkout-index' accepts `--stdin` it would be faster to use:
+since `git checkout-index` accepts `--stdin` it would be faster to use:
 
 ----------------
 $ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
@@ -102,7 +102,7 @@ Using `--` is probably a good policy in scripts.
 Using --temp or --stage=all
 ---------------------------
 When `--temp` is used (or implied by `--stage=all`)
-'git checkout-index' will create a temporary file for each index
+`git checkout-index` will create a temporary file for each index
 entry being checked out.  The index will not be updated with stat
 information.  These options can be useful if the caller needs all
 stages of all unmerged entries so that the unmerged files can be
@@ -147,9 +147,9 @@ To update and refresh only the files already checked out::
 $ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
 ----------------
 
-Using 'git checkout-index' to "export an entire tree"::
+Using `git checkout-index` to "export an entire tree"::
 	The prefix ability basically makes it trivial to use
-	'git checkout-index' as an "export as tree" function.
+	`git checkout-index` as an "export as tree" function.
 	Just read the desired tree into the index, and do:
 +
 ----------------
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 192dbfe9b0..c3fc807d91 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -8,22 +8,22 @@ git-checkout - Switch branches or restore working tree files
 SYNOPSIS
 --------
 [verse]
-'git checkout' [-q] [-f] [-m] [<branch>]
-'git checkout' [-q] [-f] [-m] --detach [<branch>]
-'git checkout' [-q] [-f] [-m] [--detach] <commit>
-'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
-'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...
-'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]
-'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]
+`git checkout` [-q] [-f] [-m] [<branch>]
+`git checkout` [-q] [-f] [-m] --detach [<branch>]
+`git checkout` [-q] [-f] [-m] [--detach] <commit>
+`git checkout` [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
+`git checkout` [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...
+`git checkout` [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]
+`git checkout` (-p|--patch) [<tree-ish>] [--] [<pathspec>...]
 
 DESCRIPTION
 -----------
 Updates files in the working tree to match the version in the index
-or the specified tree.  If no pathspec was given, 'git checkout' will
+or the specified tree.  If no pathspec was given, `git checkout` will
 also update `HEAD` to set the specified branch as the current
 branch.
 
-'git checkout' [<branch>]::
+`git checkout` [<branch>]::
 	To prepare for working on `<branch>`, switch to it by updating
 	the index and the files in the working tree, and by pointing
 	`HEAD` at the branch. Local modifications to the files in the
@@ -43,12 +43,12 @@ You could omit `<branch>`, in which case the command degenerates to
 rather expensive side-effects to show only the tracking information,
 if exists, for the current branch.
 
-'git checkout' -b|-B <new_branch> [<start point>]::
+`git checkout` -b|-B <new_branch> [<start point>]::
 
 	Specifying `-b` causes a new branch to be created as if
 	linkgit:git-branch[1] were called and then checked out.  In
 	this case you can use the `--track` or `--no-track` options,
-	which will be passed to 'git branch'.  As a convenience,
+	which will be passed to `git branch`.  As a convenience,
 	`--track` without `-b` implies branch creation; see the
 	description of `--track` below.
 +
@@ -60,11 +60,11 @@ $ git branch -f <branch> [<start point>]
 $ git checkout <branch>
 ------------
 +
-that is to say, the branch is not reset/created unless "git checkout" is
+that is to say, the branch is not reset/created unless `git checkout` is
 successful.
 
-'git checkout' --detach [<branch>]::
-'git checkout' [--detach] <commit>::
+`git checkout` --detach [<branch>]::
+`git checkout` [--detach] <commit>::
 
 	Prepare to work on top of `<commit>`, by detaching `HEAD` at it
 	(see "DETACHED HEAD" section), and updating the index and the
@@ -79,8 +79,8 @@ be used to detach `HEAD` at the tip of the branch (`git checkout
 +
 Omitting `<branch>` detaches `HEAD` at the tip of the current branch.
 
-'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...::
-'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]::
+`git checkout` [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...::
+`git checkout` [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]::
 
 	Overwrite the contents of the files that match the pathspec.
 	When the `<tree-ish>` (most often a commit) is not given,
@@ -96,7 +96,7 @@ specific side of the merge can be checked out of the index by
 using `--ours` or `--theirs`.  With `-m`, changes made to the working tree
 file can be discarded to re-create the original conflicted merge result.
 
-'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]::
+`git checkout` (-p|--patch) [<tree-ish>] [--] [<pathspec>...]::
 	This is similar to the previous mode, but lets you use the
 	interactive interface to show the "diff" output and choose which
 	hunks to use in the result.  See below for the description of
@@ -151,7 +151,7 @@ of it").
 -B <new_branch>::
 	Creates the branch `<new_branch>` and start it at `<start_point>`;
 	if it already exists, then reset it to `<start_point>`. This is
-	equivalent to running "git branch" with `-f`; see
+	equivalent to running `git branch` with `-f`; see
 	linkgit:git-branch[1] for details.
 
 -t::
@@ -333,7 +333,7 @@ Note that this option uses the no overlay mode by default (see also
 	any branch (see below for details).
 +
 You can use the `@{-N}` syntax to refer to the N-th last
-branch/commit checked out using "git checkout" operation. You may
+branch/commit checked out using `git checkout` operation. You may
 also specify `-` which is synonymous to `@{-1}`.
 +
 As a special case, you may use `A...B` as a shortcut for the
@@ -384,7 +384,7 @@ a---b---c  branch 'master' (refers to commit 'c')
 ------------
 
 When a commit is created in this state, the branch is updated to refer to
-the new commit. Specifically, 'git commit' creates a new commit `d`, whose
+the new commit. Specifically, `git commit` creates a new commit `d`, whose
 parent is commit `c`, and then updates branch `master` to refer to new
 commit `d`. `HEAD` still refers to branch `master` and so indirectly now refers
 to commit `d`:
@@ -493,7 +493,7 @@ $ git tag foo           <3>
     leaving `HEAD` detached.
 
 If we have moved away from commit `f`, then we must first recover its object
-name (typically by using git reflog), and then we can create a reference to
+name (typically by using `git reflog`), and then we can create a reference to
 it. For example, to see the last two commits to which `HEAD` referred, we
 can use either of these commands:
 
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 6069cc77a0..fb12a67778 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -8,9 +8,9 @@ git-cherry-pick - Apply the changes introduced by some existing commits
 SYNOPSIS
 --------
 [verse]
-'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff]
+`git cherry-pick` [--edit] [-n] [-m parent-number] [-s] [-x] [--ff]
 		  [-S[<keyid>]] <commit>...
-'git cherry-pick' (--continue | --skip | --abort | --quit)
+`git cherry-pick` (--continue | --skip | --abort | --quit)
 
 DESCRIPTION
 -----------
@@ -52,7 +52,7 @@ OPTIONS
 
 -e::
 --edit::
-	With this option, 'git cherry-pick' will let you edit the commit
+	With this option, `git cherry-pick` will let you edit the commit
 	message prior to committing.
 
 --cleanup=<mode>::
diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt
index 4374f398fa..ab55060668 100644
--- a/Documentation/git-cherry.txt
+++ b/Documentation/git-cherry.txt
@@ -8,7 +8,7 @@ git-cherry - Find commits yet to be applied to upstream
 SYNOPSIS
 --------
 [verse]
-'git cherry' [-v] [<upstream> [<head> [<limit>]]]
+`git cherry` [-v] [<upstream> [<head> [<limit>]]]
 
 DESCRIPTION
 -----------
@@ -16,7 +16,7 @@ Determine whether there are commits in `<head>..<upstream>` that are
 equivalent to those in the range `<limit>..<head>`.
 
 The equivalence test is based on the diff, after removing whitespace
-and line numbers.  git-cherry therefore detects when commits have been
+and line numbers.  `git-cherry` therefore detects when commits have been
 "copied" by means of linkgit:git-cherry-pick[1], linkgit:git-am[1] or
 linkgit:git-rebase[1].
 
@@ -45,7 +45,7 @@ EXAMPLES
 Patch workflows
 ~~~~~~~~~~~~~~~
 
-git-cherry is frequently used in patch-based workflows (see
+`git-cherry` is frequently used in patch-based workflows (see
 linkgit:gitworkflows[7]) to determine if a series of patches has been
 applied by the upstream maintainer.  In such a workflow you might
 create and send a topic branch like this:
@@ -85,7 +85,7 @@ $ git log --graph --oneline --decorate --boundary origin/master...topic
 o 1234567 branch point
 ------------
 
-In such cases, git-cherry shows a concise summary of what has yet to
+In such cases, `git-cherry` shows a concise summary of what has yet to
 be applied:
 
 ------------
diff --git a/Documentation/git-citool.txt b/Documentation/git-citool.txt
index c7a11c36c1..f750f754ae 100644
--- a/Documentation/git-citool.txt
+++ b/Documentation/git-citool.txt
@@ -8,16 +8,16 @@ git-citool - Graphical alternative to git-commit
 SYNOPSIS
 --------
 [verse]
-'git citool'
+`git citool`
 
 DESCRIPTION
 -----------
 A Tcl/Tk based graphical interface to review modified files, stage
 them into the index, enter a commit message and record the new
 commit onto the current branch.  This interface is an alternative
-to the less interactive 'git commit' program.
+to the less interactive `git commit` program.
 
-'git citool' is actually a standard alias for `git gui citool`.
+`git citool` is actually a standard alias for `git gui citool`.
 See linkgit:git-gui[1] for more details.
 
 GIT
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index cbec3e649a..7923ae27a5 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
 SYNOPSIS
 --------
 [verse]
-'git clean' [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] <path>...
+`git clean` [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] <path>...
 
 DESCRIPTION
 -----------
@@ -26,19 +26,19 @@ are affected.
 OPTIONS
 -------
 -d::
-	Normally, when no <path> is specified, git clean will not
+	Normally, when no <path> is specified, `git clean` will not
 	recurse into untracked directories to avoid removing too much.
 	Specify `-d` to have it recurse into such directories as well.
 	If any paths are specified, `-d` is irrelevant; all untracked
 	files matching the specified paths (with exceptions for nested
-	git directories mentioned under `--force`) will be removed.
+	`git` directories mentioned under `--force`) will be removed.
 
 -f::
 --force::
 	If the Git configuration variable `clean.requireForce` is not set
-	to false, 'git clean' will refuse to delete files or directories
+	to false, `git clean` will refuse to delete files or directories
 	unless given `-f` or `-i`.  Git will refuse to modify untracked
-	nested git repositories (directories with a .git subdirectory)
+	nested `git` repositories (directories with a .git subdirectory)
 	unless a second `-f` is given.
 
 -i::
@@ -65,7 +65,7 @@ OPTIONS
 	still use the ignore rules given with `-e` options from the command
 	line.  This allows removing all untracked
 	files, including build products.  This can be used (possibly in
-	conjunction with 'git restore' or 'git reset') to create a pristine
+	conjunction with `git restore` or `git reset`) to create a pristine
 	working directory to test a clean build.
 
 -X::
@@ -131,7 +131,7 @@ quit::
 
 help::
 
-  Show brief usage of interactive git-clean.
+  Show brief usage of interactive `git-clean`.
 
 SEE ALSO
 --------
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 8cd602a852..b8ca823467 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -9,7 +9,7 @@ git-clone - Clone a repository into a new directory
 SYNOPSIS
 --------
 [verse]
-'git clone' [--template=<template_directory>]
+`git clone` [--template=<template_directory>]
 	  [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
 	  [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
 	  [--dissociate] [--separate-git-dir <git dir>]
diff --git a/Documentation/git-column.txt b/Documentation/git-column.txt
index ab545fc52d..0865d22bdc 100644
--- a/Documentation/git-column.txt
+++ b/Documentation/git-column.txt
@@ -8,14 +8,14 @@ git-column - Display data in columns
 SYNOPSIS
 --------
 [verse]
-'git column' [--command=<name>] [--[raw-]mode=<mode>] [--width=<width>]
+`git column` [--command=<name>] [--[raw-]mode=<mode>] [--width=<width>]
 	     [--indent=<string>] [--nl=<string>] [--padding=<n>]
 
 DESCRIPTION
 -----------
 This command formats the lines of its standard input into a table with
 multiple columns. Each input line occupies one cell of the table. It
-is used internally by other git commands to format output into
+is used internally by other `git` commands to format output into
 columns.
 
 OPTIONS
diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-commit-graph.txt
index e1f48c95b3..3246616b10 100644
--- a/Documentation/git-commit-graph.txt
+++ b/Documentation/git-commit-graph.txt
@@ -9,8 +9,8 @@ git-commit-graph - Write and verify Git commit-graph files
 SYNOPSIS
 --------
 [verse]
-'git commit-graph verify' [--object-dir <dir>] [--shallow] [--[no-]progress]
-'git commit-graph write' <options> [--object-dir <dir>] [--[no-]progress]
+`git commit-graph verify` [--object-dir <dir>] [--shallow] [--[no-]progress]
+`git commit-graph write` <options> [--object-dir <dir>] [--[no-]progress]
 
 
 DESCRIPTION
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
index b76a825c94..48a76dd029 100644
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -9,8 +9,8 @@ git-commit-tree - Create a new commit object
 SYNOPSIS
 --------
 [verse]
-'git commit-tree' <tree> [(-p <parent>)...]
-'git commit-tree' [(-p <parent>)...] [-S[<keyid>]] [(-m <message>)...]
+`git commit-tree` <tree> [(-p <parent>)...]
+`git commit-tree` [(-p <parent>)...] [-S[<keyid>]] [(-m <message>)...]
 		  [(-F <file>)...] <tree>
 
 
@@ -77,7 +77,7 @@ A commit encapsulates:
 - committer name and email and the commit time.
 
 A commit comment is read from stdin. If a changelog
-entry is not provided via "<" redirection, 'git commit-tree' will just wait
+entry is not provided via "<" redirection, `git commit-tree` will just wait
 for one to be entered and terminated with ^D.
 
 include::date-formats.txt[]
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 6d10f2bdc7..3b22ba718c 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -8,7 +8,7 @@ git-commit - Record changes to the repository
 SYNOPSIS
 --------
 [verse]
-'git commit' [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
+`git commit` [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
 	   [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>)]
 	   [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
 	   [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
@@ -58,7 +58,7 @@ summary of what is included by any of the above for the next
 commit by giving the same set of parameters (options and paths).
 
 If you make a commit and then find a mistake immediately after
-that, you can recover from it with 'git reset'.
+that, you can recover from it with `git reset`.
 
 :git-commit: 1
 
@@ -310,7 +310,7 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
 	of the paths specified on the
 	command line, disregarding any contents that have been
 	staged for other paths. This is the default mode of operation of
-	'git commit' if any paths are given on the command line,
+	`git commit` if any paths are given on the command line,
 	in which case this option can be omitted.
 	If this option is specified together with `--amend`, then
 	no paths need to be specified, which can be used to amend
@@ -409,10 +409,10 @@ EXAMPLES
 --------
 When recording your own work, the contents of modified files in
 your working tree are temporarily stored to a staging area
-called the "index" with 'git add'.  A file can be
+called the "index" with `git add`.  A file can be
 reverted back, only in the index but not in the working tree,
 to that of the last commit with `git restore --staged <file>`,
-which effectively reverts 'git add' and prevents the changes to
+which effectively reverts `git add` and prevents the changes to
 this file from participating in the next commit.  After building
 the state to be committed incrementally with these commands,
 `git commit` (without any pathname parameter) is used to record what
@@ -468,13 +468,13 @@ $ git commit
 this second commit would record the changes to `hello.c` and
 `hello.h` as expected.
 
-After a merge (initiated by 'git merge' or 'git pull') stops
+After a merge (initiated by `git merge` or `git pull`) stops
 because of conflicts, cleanly merged
 paths are already staged to be committed for you, and paths that
 conflicted are left in unmerged state.  You would have to first
-check which paths are conflicting with 'git status'
+check which paths are conflicting with `git status`
 and after fixing them manually in your working tree, you would
-stage the result as usual with 'git add':
+stage the result as usual with `git add`:
 
 ------------
 $ git status | grep unmerged
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 606411c816..85e02aff92 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -9,21 +9,21 @@ git-config - Get and set repository or global options
 SYNOPSIS
 --------
 [verse]
-'git config' [<file-option>] [--type=<type>] [--fixed-value] [--show-origin] [--show-scope] [-z|--null] name [value [value-pattern]]
-'git config' [<file-option>] [--type=<type>] --add name value
-'git config' [<file-option>] [--type=<type>] [--fixed-value] --replace-all name value [value-pattern]
-'git config' [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get name [value-pattern]
-'git config' [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get-all name [value-pattern]
-'git config' [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] [--name-only] --get-regexp name_regex [value-pattern]
-'git config' [<file-option>] [--type=<type>] [-z|--null] --get-urlmatch name URL
-'git config' [<file-option>] [--fixed-value] --unset name [value-pattern]
-'git config' [<file-option>] [--fixed-value] --unset-all name [value-pattern]
-'git config' [<file-option>] --rename-section old_name new_name
-'git config' [<file-option>] --remove-section name
-'git config' [<file-option>] [--show-origin] [--show-scope] [-z|--null] [--name-only] -l | --list
-'git config' [<file-option>] --get-color name [default]
-'git config' [<file-option>] --get-colorbool name [stdout-is-tty]
-'git config' [<file-option>] -e | --edit
+`git config` [<file-option>] [--type=<type>] [--fixed-value] [--show-origin] [--show-scope] [-z|--null] name [value [value-pattern]]
+`git config` [<file-option>] [--type=<type>] --add name value
+`git config` [<file-option>] [--type=<type>] [--fixed-value] --replace-all name value [value-pattern]
+`git config` [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get name [value-pattern]
+`git config` [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get-all name [value-pattern]
+`git config` [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] [--name-only] --get-regexp name_regex [value-pattern]
+`git config` [<file-option>] [--type=<type>] [-z|--null] --get-urlmatch name URL
+`git config` [<file-option>] [--fixed-value] --unset name [value-pattern]
+`git config` [<file-option>] [--fixed-value] --unset-all name [value-pattern]
+`git config` [<file-option>] --rename-section old_name new_name
+`git config` [<file-option>] --remove-section name
+`git config` [<file-option>] [--show-origin] [--show-scope] [-z|--null] [--name-only] -l | --list
+`git config` [<file-option>] --get-color name [default]
+`git config` [<file-option>] --get-colorbool name [stdout-is-tty]
+`git config` [<file-option>] -e | --edit
 
 DESCRIPTION
 -----------
@@ -41,7 +41,7 @@ prepend a single exclamation mark in front (see also <<EXAMPLES>>),
 but note that this only works when the `--fixed-value` option is not
 in use.
 
-The `--type=<type>` option instructs 'git config' to ensure that incoming and
+The `--type=<type>` option instructs `git config` to ensure that incoming and
 outgoing values are canonicalize-able under the given <type>.  If no
 `--type=<type>` is given, no canonicalization will be performed. Callers may
 unset an existing `--type` specifier with `--no-type`.
@@ -175,7 +175,7 @@ See also <<FILES>>.
 	is exactly equal to the `value-pattern`.
 
 --type <type>::
-  'git config' will ensure that any input or output is valid under the given
+  `git config` will ensure that any input or output is valid under the given
   type constraint(s), and will canonicalize outgoing values in `<type>`'s
   canonical form.
 +
@@ -209,7 +209,7 @@ Valid `<type>`'s include:
 
 --no-type::
   Un-sets the previously set type specifier (if one was previously set). This
-  option requests that 'git config' not canonicalize the retrieved variable.
+  option requests that `git config` not canonicalize the retrieved variable.
   `--no-type` has no effect without `--type=<type>` or `--<type>`.
 
 -z::
@@ -284,7 +284,7 @@ FILES
 -----
 
 If not set explicitly with `--file`, there are four files where
-'git config' will search for configuration options:
+`git config` will search for configuration options:
 
 $(prefix)/etc/gitconfig::
 	System-wide configuration file.
@@ -311,7 +311,7 @@ $GIT_DIR/config.worktree::
 If no further options are given, all reading options will read all of these
 files that are available. If the global or the system-wide configuration
 file are not available they will be ignored. If the repository configuration
-file is not available or readable, 'git config' will exit with a non-zero
+file is not available or readable, `git config` will exit with a non-zero
 error code. However, in neither case will an error message be issued.
 
 The files are read in the order given above, with last value found taking
@@ -358,7 +358,7 @@ GIT_CONFIG_VALUE_<n>::
 	in configuration files, but will be overridden by any explicit options
 	passed via `git -c`.
 +
-This is useful for cases where you want to spawn multiple git commands
+This is useful for cases where you want to spawn multiple `git` commands
 with a common configuration but cannot depend on a configuration file,
 for example when writing scripts.
 
diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
index d12ce08789..a52bd618c4 100644
--- a/Documentation/git-count-objects.txt
+++ b/Documentation/git-count-objects.txt
@@ -8,7 +8,7 @@ git-count-objects - Count unpacked number of objects and their disk consumption
 SYNOPSIS
 --------
 [verse]
-'git count-objects' [-v] [-H | --human-readable]
+`git count-objects` [-v] [-H | --human-readable]
 
 DESCRIPTION
 -----------
diff --git a/Documentation/git-credential-cache--daemon.txt b/Documentation/git-credential-cache--daemon.txt
index 7051c6bdf8..ed4d4c4f35 100644
--- a/Documentation/git-credential-cache--daemon.txt
+++ b/Documentation/git-credential-cache--daemon.txt
@@ -8,7 +8,7 @@ git-credential-cache--daemon - Temporarily store user credentials in memory
 SYNOPSIS
 --------
 [verse]
-git credential-cache--daemon [--debug] <socket>
+`git credential-cache--daemon` [--debug] <socket>
 
 DESCRIPTION
 -----------
diff --git a/Documentation/git-credential-cache.txt b/Documentation/git-credential-cache.txt
index b1a9d9b29a..e9834b8b95 100644
--- a/Documentation/git-credential-cache.txt
+++ b/Documentation/git-credential-cache.txt
@@ -8,7 +8,7 @@ git-credential-cache - Helper to temporarily store passwords in memory
 SYNOPSIS
 --------
 -----------------------------
-git config credential.helper 'cache [<options>]'
+`git config` credential.helper 'cache [<options>]'
 -----------------------------
 
 DESCRIPTION
diff --git a/Documentation/git-credential-store.txt b/Documentation/git-credential-store.txt
index 76b0798856..376b0d6c5f 100644
--- a/Documentation/git-credential-store.txt
+++ b/Documentation/git-credential-store.txt
@@ -8,7 +8,7 @@ git-credential-store - Helper to store credentials on disk
 SYNOPSIS
 --------
 -------------------
-git config credential.helper 'store [<options>]'
+`git config` credential.helper 'store [<options>]'
 -------------------
 
 DESCRIPTION
@@ -45,7 +45,7 @@ FILES
 -----
 
 If not set explicitly with `--file`, there are two files where
-git-credential-store will search for credentials in order of precedence:
+`git-credential-store` will search for credentials in order of precedence:
 
 ~/.git-credentials::
 	User-specific credentials file.
diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt
index 31c81c4c02..9bfcb3f90a 100644
--- a/Documentation/git-credential.txt
+++ b/Documentation/git-credential.txt
@@ -8,7 +8,7 @@ git-credential - Retrieve and store user credentials
 SYNOPSIS
 --------
 ------------------
-git credential <fill|approve|reject>
+`git credential` <fill|approve|reject>
 ------------------
 
 DESCRIPTION
@@ -16,28 +16,28 @@ DESCRIPTION
 
 Git has an internal interface for storing and retrieving credentials
 from system-specific helpers, as well as prompting the user for
-usernames and passwords. The git-credential command exposes this
+usernames and passwords. The `git-credential` command exposes this
 interface to scripts which may want to retrieve, store, or prompt for
 credentials in the same manner as Git. The design of this scriptable
 interface models the internal C API; see credential.h for more
 background on the concepts.
 
-git-credential takes an "action" option on the command-line (one of
+`git-credential` takes an "action" option on the command-line (one of
 `fill`, `approve`, or `reject`) and reads a credential description
 on stdin (see <<IOFMT,INPUT/OUTPUT FORMAT>>).
 
-If the action is `fill`, git-credential will attempt to add "username"
+If the action is `fill`, `git-credential` will attempt to add "username"
 and "password" attributes to the description by reading config files,
 by contacting any configured credential helpers, or by prompting the
 user. The username and password attributes of the credential
 description are then printed to stdout together with the attributes
 already provided.
 
-If the action is `approve`, git-credential will send the description
+If the action is `approve`, `git-credential` will send the description
 to any configured credential helpers, which may store the credential
 for later use.
 
-If the action is `reject`, git-credential will send the description to
+If the action is `reject`, `git-credential` will send the description to
 any configured credential helpers, which may erase any stored
 credential matching the description.
 
@@ -46,7 +46,7 @@ If the action is `approve` or `reject`, no output should be emitted.
 TYPICAL USE OF GIT CREDENTIAL
 -----------------------------
 
-An application using git-credential will typically use `git
+An application using `git-credential` will typically use `git
 credential` following these steps:
 
   1. Generate a credential description based on the context.
@@ -61,7 +61,7 @@ information it has):
 	 host=example.com
 	 path=foo.git
 
-  2. Ask git-credential to give us a username and password for this
+  2. Ask `git-credential` to give us a username and password for this
      description. This is done by running `git credential fill`,
      feeding the description from step (1) to its standard input. The complete
      credential description (including the credential per se, i.e. the
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index 76b16f9dae..596512ec73 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -9,7 +9,7 @@ git-cvsexportcommit - Export a single commit to a CVS checkout
 SYNOPSIS
 --------
 [verse]
-'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot]
+`git cvsexportcommit` [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot]
 	[-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
 
 
@@ -28,7 +28,7 @@ by default.
 
 Supports file additions, removals, and commits that affect binary files.
 
-If the commit is a merge commit, you must tell 'git cvsexportcommit' what
+If the commit is a merge commit, you must tell `git cvsexportcommit` what
 parent the changeset should be done against.
 
 OPTIONS
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 95fa94de74..586184bbd4 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -9,7 +9,7 @@ git-cvsimport - Salvage your data out of another SCM people love to hate
 SYNOPSIS
 --------
 [verse]
-'git cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
+`git cvsimport` [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
 	      [-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
 	      [-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
 	      [-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
@@ -34,9 +34,9 @@ At least version 2.1 is required.
 Please see the section <<issues,ISSUES>> for further reference.
 
 You should *never* do any work of your own on the branches that are
-created by 'git cvsimport'.  By default initial import will create and populate a
+created by `git cvsimport`.  By default initial import will create and populate a
 `master` branch from the CVS repository's main branch which you're free
-to work with; after that, you need to 'git merge' incremental imports, or
+to work with; after that, you need to `git merge` incremental imports, or
 any CVS branches, yourself.  It is advisable to specify a named remote via
 `-r` to separate and protect the incoming branches.
 
@@ -55,13 +55,13 @@ OPTIONS
 -d <CVSROOT>::
 	The root of the CVS archive. May be local (a simple path) or remote;
 	currently, only the :local:, :ext: and :pserver: access methods
-	are supported. If not given, 'git cvsimport' will try to read it
+	are supported. If not given, `git cvsimport` will try to read it
 	from `CVS/Root`. If no such file exists, it checks for the
 	`CVSROOT` environment variable.
 
 <CVS_module>::
 	The CVS module you want to import. Relative to <CVSROOT>.
-	If not given, 'git cvsimport' tries to read it from
+	If not given, `git cvsimport` tries to read it from
 	`CVS/Repository`.
 
 -C <target-dir>::
@@ -71,14 +71,14 @@ OPTIONS
 -r <remote>::
 	The Git remote to import this CVS repository into.
 	Moves all CVS branches into remotes/<remote>/<branch>
-	akin to the way 'git clone' uses `origin` by default.
+	akin to the way `git clone` uses `origin` by default.
 
 -o <branch-for-HEAD>::
 	When no remote is specified (via `-r`) the `HEAD` branch
 	from CVS is imported to the `origin` branch within the Git
 	repository, as `HEAD` already has a special meaning for Git.
 	When a remote is specified the `HEAD` branch is named
-	remotes/<remote>/master mirroring 'git clone' behaviour.
+	remotes/<remote>/master mirroring `git clone` behaviour.
 	Use this option if you want to import into a different
 	branch.
 +
@@ -152,18 +152,18 @@ This option can be used several times to provide several detection regexes.
 
 ---------
 +
-'git cvsimport' will make it appear as those authors had
+`git cvsimport` will make it appear as those authors had
 their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
 all along.  If a time zone is specified, GIT_AUTHOR_DATE will
 have the corresponding offset applied.
 +
 For convenience, this data is saved to `$GIT_DIR/cvs-authors`
 each time the `-A` option is provided and read from that same
-file each time 'git cvsimport' is run.
+file each time `git cvsimport` is run.
 +
 It is not recommended to use this feature if you intend to
 export changes back to CVS again later with
-'git cvsexportcommit'.
+`git cvsexportcommit`.
 
 -R::
 	Generate a `$GIT_DIR/cvs-revisions` file containing a mapping from CVS
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index c6a926d8d2..bf53d16a7f 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -17,12 +17,12 @@ export CVS_SERVER="git cvsserver"
 pserver (/etc/inetd.conf):
 
 [verse]
-cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
+cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver `git-cvsserver` pserver
 
 Usage:
 
 [verse]
-'git-cvsserver' [<options>] [pserver|server] [<directory> ...]
+`git-cvsserver` [<options>] [pserver|server] [<directory> ...]
 
 OPTIONS
 -------
@@ -74,7 +74,7 @@ LIMITATIONS
 
 CVS clients cannot tag, branch or perform Git merges.
 
-'git-cvsserver' maps Git branches to CVS modules. This is very different
+`git-cvsserver` maps Git branches to CVS modules. This is very different
 from what most CVS users would expect since in CVS modules usually represent
 one or more directories.
 
@@ -132,7 +132,7 @@ Then provide your password via the pserver method, for example:
 ------
 No special setup is needed for SSH access, other than having Git tools
 in the PATH. If you have clients that do not accept the CVS_SERVER
-environment variable, you can rename 'git-cvsserver' to `cvs`.
+environment variable, you can rename `git-cvsserver` to `cvs`.
 
 Note: Newer CVS versions (>= 1.12.11) also support specifying
 CVS_SERVER directly in CVSROOT like
@@ -142,9 +142,9 @@ cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>
 ------
 This has the advantage that it will be saved in your 'CVS/Root' files and
 you don't need to worry about always setting the correct environment
-variable.  SSH users restricted to 'git-shell' don't need to override the default
-with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean
-'git-cvsserver' and pretends that the other end runs the real 'cvs' better.
+variable.  SSH users restricted to `git-shell` don't need to override the default
+with CVS_SERVER (and shouldn't) as `git-shell` understands `cvs` to mean
+`git-cvsserver` and pretends that the other end runs the real 'cvs' better.
 --
 2. For each repo that you want accessible from CVS you need to edit config in
    the repo and add the following section.
@@ -157,7 +157,7 @@ with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean
 	logFile=/path/to/logfile
 
 ------
-Note: you need to ensure each user that is going to invoke 'git-cvsserver' has
+Note: you need to ensure each user that is going to invoke `git-cvsserver` has
 write access to the log file and to the database (see
 <<dbbackend,Database Backend>>. If you want to offer write access over
 SSH, the users of course also need write access to the Git repository itself.
@@ -182,7 +182,7 @@ allowing access over SSH.
    automatically saving it in your 'CVS/Root' files, then you need to set them
    explicitly in your environment.  CVSROOT should be set as per normal, but the
    directory should point at the appropriate Git repo.  As above, for SSH clients
-   _not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'.
+   _not_ restricted to `git-shell`, CVS_SERVER should be set to `git-cvsserver`.
 +
 --
 ------
@@ -210,32 +210,32 @@ allowing access over SSH.
 DATABASE BACKEND
 ----------------
 
-'git-cvsserver' uses one database per Git head (i.e. CVS module) to
+`git-cvsserver` uses one database per Git head (i.e. CVS module) to
 store information about the repository to maintain consistent
 CVS revision numbers. The database needs to be
 updated (i.e. written to) after every commit.
 
 If the commit is done directly by using `git` (as opposed to
-using 'git-cvsserver') the update will need to happen on the
-next repository access by 'git-cvsserver', independent of
+using `git-cvsserver`) the update will need to happen on the
+next repository access by `git-cvsserver`, independent of
 access method and requested operation.
 
 That means that even if you offer only read access (e.g. by using
-the pserver method), 'git-cvsserver' should have write access to
+the pserver method), `git-cvsserver` should have write access to
 the database to work reliably (otherwise you need to make sure
-that the database is up to date any time 'git-cvsserver' is executed).
+that the database is up to date any time `git-cvsserver` is executed).
 
 By default it uses SQLite databases in the Git directory, named
 `gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates
 temporary files in the same directory as the database file on
 write so it might not be enough to grant the users using
-'git-cvsserver' write access to the database file without granting
+`git-cvsserver` write access to the database file without granting
 them write access to the directory, too.
 
 The database cannot be reliably regenerated in a
 consistent form after the branch it is tracking has changed.
-Example: For merged branches, 'git-cvsserver' only tracks
-one branch of development, and after a 'git merge' an
+Example: For merged branches, `git-cvsserver` only tracks
+one branch of development, and after a `git merge` an
 incrementally updated database may track a different branch
 than a database regenerated from scratch, causing inconsistent
 CVS revision numbers. `git-cvsserver` has no way of knowing which
@@ -250,7 +250,7 @@ configuration variables:
 Configuring database backend
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-'git-cvsserver' uses the Perl DBI module. Please also read
+`git-cvsserver` uses the Perl DBI module. Please also read
 its documentation if changing these variables, especially
 about `DBI->connect()`.
 
@@ -302,7 +302,7 @@ In `dbDriver` and `dbUser` you can use the following variables:
 %a::
 	access method (one of "ext" or "pserver")
 %u::
-	Name of the user running 'git-cvsserver'.
+	Name of the user running `git-cvsserver`.
 	If no name can be determined, the
 	numeric uid is used.
 
@@ -310,13 +310,13 @@ ENVIRONMENT
 -----------
 
 These variables obviate the need for command-line options in some
-circumstances, allowing easier restricted usage through git-shell.
+circumstances, allowing easier restricted usage through `git-shell`.
 
 GIT_CVSSERVER_BASE_PATH takes the place of the argument to `--base-path`.
 
 GIT_CVSSERVER_ROOT specifies a single-directory whitelist. The
 repository must still be configured to allow access through
-git-cvsserver, as described above.
+`git-cvsserver`, as described above.
 
 When these environment variables are set, the corresponding
 command-line arguments may not be used.
@@ -343,8 +343,8 @@ you will definitely want to have SSH keys setup.
 
 Alternatively, you can just use the non-standard extssh protocol that Eclipse
 offer. In that case CVS_SERVER is ignored, and you will have to replace
-the cvs utility on the server with 'git-cvsserver' or manipulate your `.bashrc`
-so that calling 'cvs' effectively calls 'git-cvsserver'.
+the cvs utility on the server with `git-cvsserver` or manipulate your `.bashrc`
+so that calling 'cvs' effectively calls `git-cvsserver`.
 
 CLIENTS KNOWN TO WORK
 ---------------------
@@ -361,12 +361,12 @@ All the operations required for normal use are supported, including
 checkout, diff, status, update, log, add, remove, commit.
 
 Most CVS command arguments that read CVS tags or revision numbers
-(typically `-r`) work, and also support any git refspec
+(typically `-r`) work, and also support any `git` refspec
 (tag, branch, commit ID, etc).
 However, CVS revision numbers for non-default branches are not well
 emulated, and cvs log does not show tags or branches at
 all.  (Non-main-branch CVS revision numbers superficially resemble CVS
-revision numbers, but they actually encode a git commit ID directly,
+revision numbers, but they actually encode a `git` commit ID directly,
 rather than represent the number of revisions since the branch point.)
 
 Note that there are two ways to checkout a particular branch.
@@ -383,9 +383,9 @@ operations against that main branch are fast.  Or alternatively,
 -r doesn't take any extra disk space, but may be significantly slower for
 many operations, like cvs update.
 
-If you want to refer to a git refspec that has characters that are
+If you want to refer to a `git` refspec that has characters that are
 not allowed by CVS, you have two options.  First, it may just work
-to supply the git refspec directly to the appropriate CVS `-r` argument;
+to supply the `git` refspec directly to the appropriate CVS `-r` argument;
 some CVS clients don't seem to do much sanity checking of the argument.
 Second, if that fails, you can use a special character escape mechanism
 that only uses characters that are valid in CVS tags.  A sequence
@@ -426,7 +426,7 @@ and `gitcvs.allBinary` to "guess".
 
 DEPENDENCIES
 ------------
-'git-cvsserver' depends on DBD::SQLite.
+`git-cvsserver` depends on DBD::SQLite.
 
 GIT
 ---
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 2794a2d0c1..e9cce4e468 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -8,7 +8,7 @@ git-daemon - A really simple server for Git repositories
 SYNOPSIS
 --------
 [verse]
-'git daemon' [--verbose] [--syslog] [--export-all]
+`git daemon` [--verbose] [--syslog] [--export-all]
 	     [--timeout=<n>] [--init-timeout=<n>] [--max-connections=<n>]
 	     [--strict-paths] [--base-path=<path>] [--base-path-relaxed]
 	     [--user-path | --user-path=<path>]
@@ -29,39 +29,39 @@ A really simple TCP Git daemon that normally listens on port "DEFAULT_GIT_PORT"
 aka 9418.  It waits for a connection asking for a service, and will serve
 that service if it is enabled.
 
-It verifies that the directory has the magic file "git-daemon-export-ok", and
+It verifies that the directory has the magic file `git-daemon-export-ok`, and
 it will refuse to export any Git directory that hasn't explicitly been marked
 for export this way (unless the `--export-all` parameter is specified). If you
-pass some directory paths as 'git daemon' arguments, you can further restrict
+pass some directory paths as `git daemon` arguments, you can further restrict
 the offers to a whitelist comprising of those.
 
 By default, only `upload-pack` service is enabled, which serves
-'git fetch-pack' and 'git ls-remote' clients, which are invoked
-from 'git fetch', 'git pull', and 'git clone'.
+`git fetch-pack` and `git ls-remote` clients, which are invoked
+from `git fetch`, `git pull`, and `git clone`.
 
 This is ideally suited for read-only updates, i.e., pulling from
 Git repositories.
 
-An `upload-archive` also exists to serve 'git archive'.
+An `upload-archive` also exists to serve `git archive`.
 
 OPTIONS
 -------
 --strict-paths::
 	Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
 	"/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
-	'git daemon' will refuse to start when this option is enabled and no
+	`git daemon` will refuse to start when this option is enabled and no
 	whitelist is specified.
 
 --base-path=<path>::
 	Remap all the path requests as relative to the given path.
-	This is sort of "Git root" - if you run 'git daemon' with
+	This is sort of "Git root" - if you run `git daemon` with
 	`--base-path=/srv/git` on example.com, then if you later try to pull
-	'git://example.com/hello.git', 'git daemon' will interpret the path
+	'git://example.com/hello.git', `git daemon` will interpret the path
 	as `/srv/git/hello.git`.
 
 --base-path-relaxed::
 	If `--base-path` is enabled and repo lookup fails, with this option
-	'git daemon' will attempt to lookup without prefixing the base path.
+	`git daemon` will attempt to lookup without prefixing the base path.
 	This is useful for switching to `--base-path` usage, while still
 	allowing the old paths.
 
@@ -78,7 +78,7 @@ OPTIONS
 --export-all::
 	Allow pulling from all directories that look like Git repositories
 	(have the 'objects' and 'refs' subdirectories), even if they
-	do not have the 'git-daemon-export-ok' file.
+	do not have the `git-daemon-export-ok` file.
 
 --inetd::
 	Have the server run as an inetd service. Implies `--syslog` (may be
@@ -170,10 +170,10 @@ otherwise `stderr`.
 +
 Giving these options is an error when used with `--inetd`; use
 the facility of inet daemon to achieve the same before spawning
-'git daemon' if needed.
+`git daemon` if needed.
 +
 Like many programs that switch user id, the daemon does not reset
-environment variables such as `$HOME` when it runs git programs,
+environment variables such as `$HOME` when it runs `git` programs,
 e.g. `upload-pack` and `receive-pack`. When using this option, you
 may also want to set and export `HOME` to point at the home
 directory of `<user>` before starting the daemon, and make sure any
@@ -194,7 +194,7 @@ Git configuration files in that directory are readable by `<user>`.
 	may be overridden.
 
 --[no-]informative-errors::
-	When informative errors are turned on, git-daemon will report
+	When informative errors are turned on, `git-daemon` will report
 	more verbose errors to the client, differentiating conditions
 	like "no such repository" from "repository not exported". This
 	is more convenient for clients, but may leak information about
@@ -227,24 +227,24 @@ SERVICES
 
 These services can be globally enabled/disabled using the
 command-line options of this command.  If finer-grained
-control is desired (e.g. to allow 'git archive' to be run
+control is desired (e.g. to allow `git archive` to be run
 against only in a few selected repositories the daemon serves),
 the per-repository configuration file can be used to enable or
 disable them.
 
 upload-pack::
-	This serves 'git fetch-pack' and 'git ls-remote'
+	This serves `git fetch-pack` and `git ls-remote`
 	clients.  It is enabled by default, but a repository can
 	disable it by setting `daemon.uploadpack` configuration
 	item to `false`.
 
 upload-archive::
-	This serves 'git archive --remote'.  It is disabled by
+	This serves `git archive --remote`.  It is disabled by
 	default, but a repository can enable it by setting
 	`daemon.uploadarch` configuration item to `true`.
 
 receive-pack::
-	This serves 'git send-pack' clients, allowing anonymous
+	This serves `git send-pack` clients, allowing anonymous
 	push.  It is disabled by default, as there is _no_
 	authentication in the protocol (in other words, anybody
 	can push anything into the repository, including removal
@@ -262,8 +262,8 @@ $ grep 9418 /etc/services
 git		9418/tcp		# Git Version Control System
 ------------
 
-'git daemon' as inetd server::
-	To set up 'git daemon' as an inetd service that handles any
+`git daemon` as inetd server::
+	To set up `git daemon` as an inetd service that handles any
 	repository under the whitelisted set of directories, /pub/foo
 	and /pub/bar, place an entry like the following into
 	/etc/inetd all on one line:
@@ -275,8 +275,8 @@ git		9418/tcp		# Git Version Control System
 ------------------------------------------------
 
 
-'git daemon' as inetd server for virtual hosts::
-	To set up 'git daemon' as an inetd service that handles
+`git daemon` as inetd server for virtual hosts::
+	To set up `git daemon` as an inetd service that handles
 	repositories for different virtual hosts, `www.example.com`
 	and `www.example.org`, place an entry like the following into
 	`/etc/inetd` all on one line:
@@ -298,8 +298,8 @@ clients, a symlink from `/software` into the appropriate
 default repository could be made as well.
 
 
-'git daemon' as regular daemon for virtual hosts::
-	To set up 'git daemon' as a regular, non-inetd service that
+`git daemon` as regular daemon for virtual hosts::
+	To set up `git daemon` as a regular, non-inetd service that
 	handles repositories for multiple virtual hosts based on
 	their IP addresses, start the daemon like this:
 +
@@ -316,7 +316,7 @@ Repositories can still be accessed by hostname though, assuming
 they correspond to these IP addresses.
 
 selectively enable/disable services per repository::
-	To enable 'git archive --remote' and disable 'git fetch' against
+	To enable `git archive --remote` and disable `git fetch` against
 	a repository, have the following in the configuration file in the
 	repository (that is the file 'config' next to `HEAD`, 'refs' and
 	'objects').
@@ -330,7 +330,7 @@ selectively enable/disable services per repository::
 
 ENVIRONMENT
 -----------
-'git daemon' will set REMOTE_ADDR to the IP address of the client
+`git daemon` will set REMOTE_ADDR to the IP address of the client
 that connected to it, if the IP address is available. REMOTE_ADDR will
 be available in the environment of hooks called when
 services are performed.
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 7d2649c477..6cfb444444 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -8,9 +8,9 @@ git-describe - Give an object a human readable name based on an available ref
 SYNOPSIS
 --------
 [verse]
-'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] [<commit-ish>...]
-'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
-'git describe' <blob>
+`git describe` [--all] [--tags] [--contains] [--abbrev=<n>] [<commit-ish>...]
+`git describe` [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
+`git describe` <blob>
 
 DESCRIPTION
 -----------
@@ -20,7 +20,7 @@ shown.  Otherwise, it suffixes the tag name with the number of
 additional commits on top of the tagged object and the
 abbreviated object name of the most recent commit. The result
 is a "human-readable" object name which can also be used to
-identify the commit to other git commands.
+identify the commit to other `git` commands.
 
 By default (without `--all` or `--tags`) `git describe` only shows
 annotated tags.  For more information about creating annotated tags
@@ -40,8 +40,8 @@ OPTIONS
 --dirty[=<mark>]::
 --broken[=<mark>]::
 	Describe the state of the working tree.  When the working
-	tree matches `HEAD`, the output is the same as "git describe
-	HEAD".  If the working tree has local modification "-dirty"
+	tree matches `HEAD`, the output is the same as `git describe
+	HEAD`.  If the working tree has local modification "-dirty"
 	is appended to it.  If a repository is corrupt and Git
 	cannot determine if there is local modification, Git will
 	error out, unless `--broken' is given, which appends
@@ -138,14 +138,14 @@ an abbreviated object name for the commit itself ("2414721")
 at the end.
 
 The number of additional commits is the number
-of commits which would be displayed by "git log v1.0.4..parent".
+of commits which would be displayed by `git log v1.0.4..parent`.
 The hash suffix is "-g" + unambiguous abbreviation for the tip commit
 of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
-The "g" prefix stands for "git" and is used to allow describing the version of
+The "g" prefix stands for `git` and is used to allow describing the version of
 a software depending on the SCM the software is managed with. This is useful
 in an environment where people may use different SCMs.
 
-Doing a 'git describe' on a tag-name will just show the tag name:
+Doing a `git describe` on a tag-name will just show the tag name:
 
 	[torvalds@g5 git]$ git describe v1.0.4
 	v1.0.4
@@ -175,13 +175,13 @@ be sufficient to disambiguate these commits.
 SEARCH STRATEGY
 ---------------
 
-For each commit-ish supplied, 'git describe' will first look for
+For each commit-ish supplied, `git describe` will first look for
 a tag which tags exactly that commit.  Annotated tags will always
 be preferred over lightweight tags, and tags with newer dates will
 always be preferred over tags with older dates.  If an exact match
 is found, its name will be output and searching will stop.
 
-If an exact match was not found, 'git describe' will walk back
+If an exact match was not found, `git describe` will walk back
 through the commit history to locate an ancestor commit which
 has been tagged.  The ancestor's tag will be output along with an
 abbreviation of the input commit-ish's SHA-1. If `--first-parent` was
diff --git a/Documentation/git-diff-files.txt b/Documentation/git-diff-files.txt
index 906774f0f7..b0fb276b99 100644
--- a/Documentation/git-diff-files.txt
+++ b/Documentation/git-diff-files.txt
@@ -9,14 +9,14 @@ git-diff-files - Compares files in the working tree and the index
 SYNOPSIS
 --------
 [verse]
-'git diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
+`git diff-files` [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
 
 DESCRIPTION
 -----------
 Compares the files in the working tree and the index.  When paths
 are specified, compares only those named paths.  Otherwise all
 entries in the index are compared.  The output format is the
-same as for 'git diff-index' and 'git diff-tree'.
+same as for `git diff-index` and `git diff-tree`.
 
 OPTIONS
 -------
diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt
index 10e79a29aa..87db234e77 100644
--- a/Documentation/git-diff-index.txt
+++ b/Documentation/git-diff-index.txt
@@ -9,7 +9,7 @@ git-diff-index - Compare a tree to the working tree or index
 SYNOPSIS
 --------
 [verse]
-'git diff-index' [-m] [--cached] [--merge-base] [<common diff options>] <tree-ish> [<path>...]
+`git diff-index` [-m] [--cached] [--merge-base] [<common diff options>] <tree-ish> [<path>...]
 
 DESCRIPTION
 -----------
@@ -37,7 +37,7 @@ include::diff-options.txt[]
 -m::
 	By default, files recorded in the index but not checked
 	out are reported as deleted.  This flag makes
-	'git diff-index' say that all non-checked-out files are up
+	`git diff-index` say that all non-checked-out files are up
 	to date.
 
 include::diff-format.txt[]
@@ -54,7 +54,7 @@ CACHED MODE
 If `--cached` is specified, it allows you to ask:
 
 	show me the differences between `HEAD` and the current index
-	contents (the ones I'd write using 'git write-tree')
+	contents (the ones I'd write using `git write-tree`)
 
 For example, let's say that you have worked on your working directory, updated
 some files in the index and are ready to commit. You want to see exactly
@@ -66,7 +66,7 @@ object and compare it that way, and to do that, you just do
 Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
 done an `update-index` to make that effective in the index file.
 `git diff-files` wouldn't show anything at all, since the index file
-matches my working directory. But doing a 'git diff-index' does:
+matches my working directory. But doing a `git diff-index` does:
 
   torvalds@ppc970:~/git> git diff-index --cached HEAD
   -100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        commit.c
@@ -75,7 +75,7 @@ matches my working directory. But doing a 'git diff-index' does:
 You can see easily that the above is a rename.
 
 In fact, `git diff-index --cached` *should* always be entirely equivalent to
-actually doing a 'git write-tree' and comparing that. Except this one is much
+actually doing a `git write-tree` and comparing that. Except this one is much
 nicer for the case where you just want to check where you are.
 
 So doing a `git diff-index --cached` is basically very useful when you are
@@ -86,20 +86,20 @@ NON-CACHED MODE
 ---------------
 The "non-cached" mode takes a different approach, and is potentially
 the more useful of the two in that what it does can't be emulated with
-a 'git write-tree' + 'git diff-tree'. Thus that's the default mode.
+a `git write-tree` + `git diff-tree`. Thus that's the default mode.
 The non-cached version asks the question:
 
   show me the differences between `HEAD` and the currently checked out
   tree - index contents _and_ files that aren't up to date
 
 which is obviously a very useful question too, since that tells you what
-you *could* commit. Again, the output matches the 'git diff-tree -r'
+you *could* commit. Again, the output matches the `git diff-tree -r`
 output to a tee, but with a twist.
 
 The twist is that if some file doesn't match the index, we don't have
 a backing store thing for it, and we use the magic "all-zero" sha1 to
 show that. So let's say that you have edited `kernel/sched.c`, but
-have not actually done a 'git update-index' on it yet - there is no
+have not actually done a `git update-index` on it yet - there is no
 "object" associated with the new state, and you get:
 
   torvalds@ppc970:~/v2.6/linux> git diff-index --abbrev HEAD
@@ -110,11 +110,11 @@ not up to date and may contain new stuff. The all-zero sha1 means that to
 get the real diff, you need to look at the object in the working directory
 directly rather than do an object-to-object diff.
 
-NOTE: As with other commands of this type, 'git diff-index' does not
+NOTE: As with other commands of this type, `git diff-index` does not
 actually look at the contents of the file at all. So maybe
 `kernel/sched.c` hasn't actually changed, and it's just that you
 touched it. In either case, it's a note that you need to
-'git update-index' it to make the index be in sync.
+`git update-index` it to make the index be in sync.
 
 NOTE: You can have a mixture of files show up as "has been updated"
 and "is still dirty in the working directory" together. You can always
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index b9225cd824..56354886a4 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -9,7 +9,7 @@ git-diff-tree - Compares the content and mode of blobs found via two tree object
 SYNOPSIS
 --------
 [verse]
-'git diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
+`git diff-tree` [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
 	      [-t] [-r] [-c | --cc] [--combined-all-paths] [--root] [--merge-base]
 	      [<common diff options>] <tree-ish> [<tree-ish>] [<path>...]
 
@@ -20,7 +20,7 @@ Compares the content and mode of the blobs found via two tree objects.
 If there is only one <tree-ish> given, the commit is compared with its parents
 (see `--stdin` below).
 
-Note that 'git diff-tree' can use the tree encapsulated in a commit object.
+Note that `git diff-tree` can use the tree encapsulated in a commit object.
 
 OPTIONS
 -------
@@ -69,25 +69,25 @@ The following flags further affect the behavior when comparing
 commits (but not trees).
 
 -m::
-	By default, 'git diff-tree --stdin' does not show
+	By default, `git diff-tree --stdin` does not show
 	differences for merge commits.  With this flag, it shows
 	differences to that commit from all of its parents. See
 	also `-c`.
 
 -s::
-	By default, 'git diff-tree --stdin' shows differences,
+	By default, `git diff-tree --stdin` shows differences,
 	either in machine-readable form (without `-p`) or in patch
 	form (with `-p`).  This output can be suppressed.  It is
 	only useful with `-v` flag.
 
 -v::
-	This flag causes 'git diff-tree --stdin' to also show
+	This flag causes `git diff-tree --stdin` to also show
 	the commit message before the differences.
 
 include::pretty-options.txt[]
 
 --no-commit-id::
-	'git diff-tree' outputs a line with the commit ID when
+	`git diff-tree` outputs a line with the commit ID when
 	applicable.  This flag suppressed the commit ID output.
 
 -c::
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 33a47958bc..7779631421 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -9,12 +9,12 @@ git-diff - Show changes between commits, commit and working tree, etc
 SYNOPSIS
 --------
 [verse]
-'git diff' [<options>] [<commit>] [--] [<path>...]
-'git diff' [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]
-'git diff' [<options>] [--merge-base] <commit> [<commit>...] <commit> [--] [<path>...]
-'git diff' [<options>] <commit>...<commit> [--] [<path>...]
-'git diff' [<options>] <blob> <blob>
-'git diff' [<options>] --no-index [--] <path> <path>
+`git diff` [<options>] [<commit>] [--] [<path>...]
+`git diff` [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]
+`git diff` [<options>] [--merge-base] <commit> [<commit>...] <commit> [--] [<path>...]
+`git diff` [<options>] <commit>...<commit> [--] [<path>...]
+`git diff` [<options>] <blob> <blob>
+`git diff` [<options>] --no-index [--] <path> <path>
 
 DESCRIPTION
 -----------
@@ -23,7 +23,7 @@ between the index and a tree, changes between two trees, changes resulting
 from a merge, changes between two blob objects, or changes between two
 files on disk.
 
-'git diff' [<options>] [--] [<path>...]::
+`git diff` [<options>] [--] [<path>...]::
 
 	This form is to view the changes you made relative to
 	the index (staging area for the next commit).  In other
@@ -31,7 +31,7 @@ files on disk.
 	further add to the index but you still haven't.  You can
 	stage these changes by using linkgit:git-add[1].
 
-'git diff' [<options>] --no-index [--] <path> <path>::
+`git diff` [<options>] --no-index [--] <path> <path>::
 
 	This form is to compare the given two paths on the
 	filesystem.  You can omit the `--no-index` option when
@@ -40,7 +40,7 @@ files on disk.
 	or when running the command outside a working tree
 	controlled by Git. This form implies `--exit-code`.
 
-'git diff' [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]::
+`git diff` [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]::
 
 	This form is to view the changes you staged for the next
 	commit relative to the named <commit>.  Typically you
@@ -54,7 +54,7 @@ If `--merge-base` is given, instead of using <commit>, use the merge base
 of <commit> and `HEAD`.  `git diff --merge-base A` is equivalent to
 `git diff $(git merge-base A HEAD)`.
 
-'git diff' [<options>] <commit> [--] [<path>...]::
+`git diff` [<options>] <commit> [--] [<path>...]::
 
 	This form is to view the changes you have in your
 	working tree relative to the named <commit>.  You can
@@ -62,7 +62,7 @@ of <commit> and `HEAD`.  `git diff --merge-base A` is equivalent to
 	branch name to compare with the tip of a different
 	branch.
 
-'git diff' [<options>] [--merge-base] <commit> <commit> [--] [<path>...]::
+`git diff` [<options>] [--merge-base] <commit> <commit> [--] [<path>...]::
 
 	This is to view the changes between two arbitrary
 	<commit>.
@@ -71,7 +71,7 @@ If `--merge-base` is given, use the merge base of the two commits for the
 "before" side.  `git diff --merge-base A B` is equivalent to
 `git diff $(git merge-base A B) B`.
 
-'git diff' [<options>] <commit> <commit>... <commit> [--] [<path>...]::
+`git diff` [<options>] <commit> <commit>... <commit> [--] [<path>...]::
 
 	This form is to view the results of a merge commit.  The first
 	listed <commit> must be the merge itself; the remaining two or
@@ -80,14 +80,14 @@ If `--merge-base` is given, use the merge base of the two commits for the
 	For instance, if `master` names a merge commit, `git diff master
 	master^@` gives the same combined diff as `git show master`.
 
-'git diff' [<options>] <commit>..<commit> [--] [<path>...]::
+`git diff` [<options>] <commit>..<commit> [--] [<path>...]::
 
 	This is synonymous to the earlier form (without the `..`) for
 	viewing the changes between two arbitrary <commit>.  If <commit> on
 	one side is omitted, it will have the same effect as
 	using `HEAD` instead.
 
-'git diff' [<options>] <commit>\...<commit> [--] [<path>...]::
+`git diff` [<options>] <commit>\...<commit> [--] [<path>...]::
 
 	This form is to view the changes on the branch containing
 	and up to the second <commit>, starting at a common ancestor
@@ -107,7 +107,7 @@ and the range notations (`<commit>..<commit>` and
 `<commit>...<commit>`) do not mean a range as defined in the
 "SPECIFYING RANGES" section in linkgit:gitrevisions[7].
 
-'git diff' [<options>] <blob> <blob>::
+`git diff` [<options>] <blob> <blob>::
 
 	This form is to view the differences between the raw
 	contents of two blob objects.
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 143b0c49d7..b646654941 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -8,13 +8,13 @@ git-difftool - Show changes using common diff tools
 SYNOPSIS
 --------
 [verse]
-'git difftool' [<options>] [<commit> [<commit>]] [--] [<path>...]
+`git difftool` [<options>] [<commit> [<commit>]] [--] [<path>...]
 
 DESCRIPTION
 -----------
-'git difftool' is a Git command that allows you to compare and edit files
-between revisions using common diff tools.  'git difftool' is a frontend
-to 'git diff' and accepts the same options and arguments. See
+`git difftool` is a Git command that allows you to compare and edit files
+between revisions using common diff tools.  `git difftool` is a frontend
+to `git diff` and accepts the same options and arguments. See
 linkgit:git-diff[1].
 
 OPTIONS
@@ -48,23 +48,23 @@ OPTIONS
 	emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
 	for the list of valid <tool> settings.
 +
-If a diff tool is not specified, 'git difftool'
+If a diff tool is not specified, `git difftool`
 will use the configuration variable `diff.tool`.  If the
-configuration variable `diff.tool` is not set, 'git difftool'
+configuration variable `diff.tool` is not set, `git difftool`
 will pick a suitable default.
 +
 You can explicitly provide a full path to the tool by setting the
 configuration variable `difftool.<tool>.path`. For example, you
 can configure the absolute path to kdiff3 by setting
-`difftool.kdiff3.path`. Otherwise, 'git difftool' assumes the
+`difftool.kdiff3.path`. Otherwise, `git difftool` assumes the
 tool is available in PATH.
 +
 Instead of running one of the known diff tools,
-'git difftool' can be customized to run an alternative program
+`git difftool` can be customized to run an alternative program
 by specifying the command line to invoke in a configuration
 variable `difftool.<tool>.cmd`.
 +
-When 'git difftool' is invoked with this tool (either through the
+When `git difftool` is invoked with this tool (either through the
 `-t` or `--tool` option or the `diff.tool` configuration variable)
 the configured command line will be invoked with the following
 variables available: `$LOCAL` is set to the name of the temporary
@@ -78,24 +78,24 @@ with custom merge tool commands and has the same value as `$MERGED`.
 	Print a list of diff tools that may be used with `--tool`.
 
 --[no-]symlinks::
-	'git difftool''s default behavior is create symlinks to the
+	`git difftool`'s default behavior is create symlinks to the
 	working tree when run in `--dir-diff` mode and the right-hand
 	side of the comparison yields the same content as the file in
 	the working tree.
 +
-Specifying `--no-symlinks` instructs 'git difftool' to create copies
+Specifying `--no-symlinks` instructs `git difftool` to create copies
 instead.  `--no-symlinks` is the default on Windows.
 
 -x <command>::
 --extcmd=<command>::
 	Specify a custom command for viewing diffs.
-	'git-difftool' ignores the configured defaults and runs
+	`git-difftool` ignores the configured defaults and runs
 	`$command $LOCAL $REMOTE` when this option is specified.
 	Additionally, `$BASE` is set in the environment.
 
 -g::
 --[no-]gui::
-	When 'git-difftool' is invoked with the `-g` or `--gui` option
+	When `git-difftool` is invoked with the `-g` or `--gui` option
 	the default diff tool will be read from the configured
 	`diff.guitool` variable instead of `diff.tool`. The `--no-gui`
 	option can be used to override this setting. If `diff.guitool`
@@ -103,19 +103,19 @@ instead.  `--no-symlinks` is the default on Windows.
 	`diff.tool`, `merge.tool` until a tool is found.
 
 --[no-]trust-exit-code::
-	'git-difftool' invokes a diff tool individually on each file.
+	`git-difftool` invokes a diff tool individually on each file.
 	Errors reported by the diff tool are ignored by default.
-	Use `--trust-exit-code` to make 'git-difftool' exit when an
+	Use `--trust-exit-code` to make `git-difftool` exit when an
 	invoked diff tool returns a non-zero exit code.
 +
-'git-difftool' will forward the exit code of the invoked tool when
+`git-difftool` will forward the exit code of the invoked tool when
 `--trust-exit-code` is used.
 
 See linkgit:git-diff[1] for the full list of supported options.
 
 CONFIG VARIABLES
 ----------------
-'git difftool' falls back to 'git mergetool' config variables when the
+`git difftool` falls back to `git mergetool` config variables when the
 difftool equivalents have not been defined.
 
 diff.tool::
diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
index 3a6a77abac..24b10d4ad1 100644
--- a/Documentation/git-fast-export.txt
+++ b/Documentation/git-fast-export.txt
@@ -9,23 +9,23 @@ git-fast-export - Git data exporter
 SYNOPSIS
 --------
 [verse]
-'git fast-export [<options>]' | 'git fast-import'
+`git fast-export [<options>]` | `git fast-import`
 
 DESCRIPTION
 -----------
 This program dumps the given revisions in a form suitable to be piped
-into 'git fast-import'.
+into `git fast-import`.
 
 You can use it as a human-readable bundle replacement (see
 linkgit:git-bundle[1]), or as a format that can be edited before being
-fed to 'git fast-import' in order to do history rewrites (an ability
-relied on by tools like 'git filter-repo').
+fed to `git fast-import` in order to do history rewrites (an ability
+relied on by tools like `git filter-repo`).
 
 OPTIONS
 -------
 --progress=<n>::
 	Insert 'progress' statements every <n> objects, to be shown by
-	'git fast-import' during import.
+	`git fast-import` during import.
 
 --signed-tags=(verbatim|warn|warn-strip|strip|abort)::
 	Specify how to handle signed tags.  Since any transformation
@@ -139,7 +139,7 @@ by keeping the marks the same across runs.
 --show-original-ids::
 	Add an extra directive to the output for commits and blobs,
 	`original-oid <SHA1SUM>`.  While such directives will likely be
-	ignored by importers such as git-fast-import, it may be useful
+	ignored by importers such as `git-fast-import`, it may be useful
 	for intermediary filters (e.g. for rewriting commit messages
 	which refer to older commits, or for stripping blobs by id).
 
@@ -155,8 +155,8 @@ by keeping the marks the same across runs.
 	be specified.
 
 [<git-rev-list-args>...]::
-	A list of arguments, acceptable to 'git rev-parse' and
-	'git rev-list', that specifies the specific objects and references
+	A list of arguments, acceptable to `git rev-parse` and
+	`git rev-list`, that specifies the specific objects and references
 	to export.  For example, `master~10..master` causes the
 	current `master` reference to be exported along with all objects
 	added since its 10th ancestor commit and (unless the
@@ -191,14 +191,14 @@ referenced by that revision range contains the string
 ANONYMIZING
 -----------
 
-If the `--anonymize` option is given, git will attempt to remove all
+If the `--anonymize` option is given, `git` will attempt to remove all
 identifying information from the repository while still retaining enough
 of the original tree and history patterns to reproduce some bugs. The
-goal is that a git bug which is found on a private repository will
+goal is that a `git` bug which is found on a private repository will
 persist in the anonymized repository, and the latter can be shared with
-git developers to help solve the bug.
+`git` developers to help solve the bug.
 
-With this option, git will replace all refnames, paths, blob contents,
+With this option, `git` will replace all refnames, paths, blob contents,
 commit and tag messages, names, and email addresses in the output with
 anonymized data.  Two instances of the same string will be replaced
 equivalently (e.g., two commits with the same author will have the same
@@ -210,7 +210,7 @@ the tree is retained (e.g., if you have a root tree with 10 files and 3
 trees, so will the output), but their names and the contents of the
 files will be replaced.
 
-If you think you have found a git bug, you can start by exporting an
+If you think you have found a `git` bug, you can start by exporting an
 anonymized stream of the whole repository:
 
 ---------------------------------------------------
@@ -271,7 +271,7 @@ final pathname would be `publicdir/bar.c`.
 LIMITATIONS
 -----------
 
-Since 'git fast-import' cannot tag trees, you will not be
+Since `git fast-import` cannot tag trees, you will not be
 able to export the linux.git repository completely, as it contains
 a tag referencing a tree instead of a commit.
 
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index ff67238633..eeac242732 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -9,14 +9,14 @@ git-fast-import - Backend for fast Git data importers
 SYNOPSIS
 --------
 [verse]
-frontend | 'git fast-import' [<options>]
+frontend | `git fast-import` [<options>]
 
 DESCRIPTION
 -----------
 This program is usually not what the end user wants to run directly.
 Most end users want to use one of the existing frontend programs,
 which parses a specific type of foreign source and feeds the contents
-stored there to 'git fast-import'.
+stored there to `git fast-import`.
 
 fast-import reads a mixed command/data stream from standard input and
 writes one or more packfiles directly into the current repository.
@@ -25,7 +25,7 @@ updated branch and tag refs, fully updating the current repository
 with the newly imported data.
 
 The fast-import backend itself can import into an empty repository (one that
-has already been initialized by 'git init') or incrementally
+has already been initialized by `git init`) or incrementally
 update an existing populated repository.  Whether or not incremental
 imports are supported from a particular foreign source depends on
 the frontend program in use.
@@ -115,7 +115,7 @@ Locations of Marks Files
 	After specifying `--relative-marks` the paths specified
 	with `--import-marks`= and `--export-marks`= are relative
 	to an internal directory in the current repository.
-	In git-fast-import this means that the paths are relative
+	In `git-fast-import` this means that the paths are relative
 	to the .git/info/fast-import directory. However, other
 	importers may use a different location.
 +
@@ -166,7 +166,7 @@ Performance and Compression Tuning
 	This information may be useful after importing projects
 	whose total object set exceeds the 4 GiB packfile limit,
 	as these commits can be used as edge points during calls
-	to 'git pack-objects'.
+	to `git pack-objects`.
 
 --max-pack-size=<n>::
 	Maximum size of each output packfile.
@@ -203,9 +203,9 @@ an ideal situation, given that most conversion tools are throw-away
 
 PARALLEL OPERATION
 ------------------
-Like 'git push' or 'git fetch', imports handled by fast-import are safe to
+Like `git push` or `git fetch`, imports handled by fast-import are safe to
 run alongside parallel `git repack -a -d` or `git gc` invocations,
-or any other Git operation (including 'git prune', as loose objects
+or any other Git operation (including `git prune`, as loose objects
 are never used by fast-import).
 
 fast-import does not lock the branch or tag refs it is actively importing.
@@ -307,7 +307,7 @@ and some sanity checks on the numeric values may also be performed.
 +
 An example value is ``Tue Feb 6 11:22:18 2007 -0500''.  The Git
 parser is accurate, but a little on the lenient side.  It is the
-same parser used by 'git am' when applying patches
+same parser used by `git am` when applying patches
 received from email.
 +
 Some malformed strings may be accepted as valid dates.  In some of
@@ -343,7 +343,7 @@ time zone.
 This particular format is supplied as it's short to implement and
 may be useful to a process that wants to create a new commit
 right now, without needing to use a working directory or
-'git update-index'.
+`git update-index`.
 +
 If separate `author` and `committer` commands are used in a `commit`
 the timestamps may not match, as the system clock will be polled
@@ -509,7 +509,7 @@ their syntax.
 ^^^^^^^^^^
 The optional `encoding` command indicates the encoding of the commit
 message.  Most commits are UTF-8 and the encoding is omitted, but this
-allows importing commit messages into git without first reencoding them.
+allows importing commit messages into `git` without first reencoding them.
 
 `from`
 ^^^^^^
@@ -859,7 +859,7 @@ recommended, as the frontend does not (easily) have access to the
 complete set of bytes which normally goes into such a signature.
 If signing is required, create lightweight tags from within fast-import with
 `reset`, then create the annotated versions of those tags offline
-with the standard 'git tag' process.
+with the standard `git tag` process.
 
 `reset`
 ~~~~~~~
@@ -1120,7 +1120,7 @@ The <dataref> represents the blob, tree, or commit object at <path>
 and can be used in later 'get-mark', 'cat-blob', 'filemodify', or
 'ls' commands.
 
-If there is no file or subtree at that path, 'git fast-import' will
+If there is no file or subtree at that path, `git fast-import` will
 instead report
 
 ====
@@ -1183,14 +1183,14 @@ done::
 	abruptly at a convenient point in the stream can go
 	undetected.  This may occur, for example, if an import
 	front end dies in mid-operation without emitting SIGTERM
-	or SIGKILL at its subordinate git fast-import instance.
+	or SIGKILL at its subordinate `git fast-import` instance.
 
 `option`
 ~~~~~~~~
-Processes the specified option so that git fast-import behaves in a
+Processes the specified option so that `git fast-import` behaves in a
 way that suits the frontend's needs.
 Note that options specified by the frontend are overridden by any
-options the user may specify to git fast-import itself.
+options the user may specify to `git fast-import` itself.
 
 ....
     'option' SP <option> LF
@@ -1396,7 +1396,7 @@ is not `refs/heads/TAG_FIXUP`).
 
 When committing fixups, consider using `merge` to connect the
 commit(s) which are supplying file revisions to the fixup branch.
-Doing so will allow tools such as 'git blame' to track
+Doing so will allow tools such as `git blame` to track
 through the real commit history and properly annotate the source
 files.
 
@@ -1425,7 +1425,7 @@ Repacking Historical Data
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 If you are repacking very old imported data (e.g. older than the
 last year), consider expending some extra CPU time and supplying
-`--window=50` (or higher) when you run 'git repack'.
+`--window=50` (or higher) when you run `git repack`.
 This will take longer, but will also produce a smaller packfile.
 You only need to expend the effort once, and everyone using your
 project will benefit from the smaller repository.
@@ -1558,7 +1558,7 @@ memory footprint (less than 2.7 MiB per active branch).
 
 SIGNALS
 -------
-Sending *SIGUSR1* to the 'git fast-import' process ends the current
+Sending *SIGUSR1* to the `git fast-import` process ends the current
 packfile early, simulating a `checkpoint` command.  The impatient
 operator can use this facility to peek at the objects and refs from an
 import in progress, at the cost of some added running time and worse
diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
index 1f48f89e3e..eaca893ac8 100644
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -9,21 +9,21 @@ git-fetch-pack - Receive missing objects from another repository
 SYNOPSIS
 --------
 [verse]
-'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag]
+`git fetch-pack` [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag]
 	[--upload-pack=<git-upload-pack>]
 	[--depth=<n>] [--no-progress]
 	[-v] <repository> [<refs>...]
 
 DESCRIPTION
 -----------
-Usually you would want to use 'git fetch', which is a
+Usually you would want to use `git fetch`, which is a
 higher level wrapper of this command, instead.
 
-Invokes 'git-upload-pack' on a possibly remote repository
+Invokes `git-upload-pack` on a possibly remote repository
 and asks it to send objects missing from this repository, to
 update the named heads.  The list of commits available locally
 is found out by scanning the local refs/ hierarchy and sent to
-'git-upload-pack' running on the other end.
+`git-upload-pack` running on the other end.
 
 This command degenerates to download everything to complete the
 asked refs from the remote side when the local side does not
@@ -47,12 +47,12 @@ be in a separate packet, and the list must end with a flush packet.
 
 -q::
 --quiet::
-	Pass `-q` flag to 'git unpack-objects'; this makes the
+	Pass `-q` flag to `git unpack-objects`; this makes the
 	cloning process less verbose.
 
 -k::
 --keep::
-	Do not invoke 'git unpack-objects' on received data, but
+	Do not invoke `git unpack-objects` on received data, but
 	create a single packfile out of it instead, and store it
 	in the object database. If provided twice then the pack is
 	locked against repacking.
@@ -68,11 +68,11 @@ be in a separate packet, and the list must end with a flush packet.
 	otherwise determine the tags this option made available.
 
 --upload-pack=<git-upload-pack>::
-	Use this to specify the path to 'git-upload-pack' on the
+	Use this to specify the path to `git-upload-pack` on the
 	remote side, if is not found on your $PATH.
 	Installations of sshd ignores the user's environment
 	setup scripts for login shells (e.g. .bash_profile) and
-	your privately installed git may not be found on the system
+	your privately installed `git` may not be found on the system
 	default $PATH.  Another workaround suggested is to set
 	up your $PATH in ".bashrc", but this flag is for people
 	who do not want to pay the overhead for non-interactive
@@ -84,7 +84,7 @@ be in a separate packet, and the list must end with a flush packet.
 
 --depth=<n>::
 	Limit fetching to ancestor-chains not longer than n.
-	'git-upload-pack' treats the special depth 2147483647 as
+	`git-upload-pack` treats the special depth 2147483647 as
 	infinite even if there is an ancestor-chain that long.
 
 --shallow-since=<date>::
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 6c3f41399f..b0b5d06aad 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -9,10 +9,10 @@ git-fetch - Download objects and refs from another repository
 SYNOPSIS
 --------
 [verse]
-'git fetch' [<options>] [<repository> [<refspec>...]]
-'git fetch' [<options>] <group>
-'git fetch' --multiple [<options>] [(<repository> | <group>)...]
-'git fetch' --all [<options>]
+`git fetch` [<options>] [<repository> [<refspec>...]]
+`git fetch` [<options>] <group>
+`git fetch` --multiple [<options>] [(<repository> | <group>)...]
+`git fetch` --all [<options>]
 
 
 DESCRIPTION
@@ -30,7 +30,7 @@ configuring `remote.<name>.tagOpt`.  By using a refspec that fetches tags
 explicitly, you can fetch tags that do not point into branches you
 are interested in as well.
 
-'git fetch' can fetch from either a single named repository or URL,
+`git fetch` can fetch from either a single named repository or URL,
 or from several repositories at once if <group> is given and
 there is a `remotes.<group>` entry in the configuration file.
 (See linkgit:git-config[1]).
@@ -40,7 +40,7 @@ unless there's an upstream branch configured for the current branch.
 
 The names of refs that are fetched, together with the object names
 they point at, are written to `.git/FETCH_HEAD`.  This information
-may be used by scripts or other git commands, such as linkgit:git-pull[1].
+may be used by scripts or other `git` commands, such as linkgit:git-pull[1].
 
 OPTIONS
 -------
@@ -193,7 +193,7 @@ $ git fetch <url of origin> --prune 'refs/tags/*:refs/tags/*'
 OUTPUT
 ------
 
-The output of "git fetch" depends on the transport method used; this
+The output of `git fetch` depends on the transport method used; this
 section describes the output when fetching over the Git protocol
 (either locally or via ssh) and Smart HTTP protocol.
 
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 520d3df371..b21205d265 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -8,7 +8,7 @@ git-filter-branch - Rewrite branches
 SYNOPSIS
 --------
 [verse]
-'git filter-branch' [--setup <command>] [--subdirectory-filter <directory>]
+`git filter-branch` [--setup <command>] [--subdirectory-filter <directory>]
 	[--env-filter <command>] [--tree-filter <command>]
 	[--index-filter <command>] [--parent-filter <command>]
 	[--msg-filter <command>] [--commit-filter <command>]
@@ -18,13 +18,13 @@ SYNOPSIS
 
 WARNING
 -------
-'git filter-branch' has a plethora of pitfalls that can produce non-obvious
+`git filter-branch` has a plethora of pitfalls that can produce non-obvious
 manglings of the intended history rewrite (and can leave you with little
 time to investigate such problems since it has such abysmal performance).
 These safety and performance issues cannot be backward compatibly fixed and
 as such, its use is not recommended.  Please use an alternative history
 filtering tool such as https://github.com/newren/git-filter-repo/[git
-filter-repo].  If you still need to use 'git filter-branch', please
+filter-repo].  If you still need to use `git filter-branch`, please
 carefully read <<SAFETY>> (and <<PERFORMANCE>>) to learn about the land
 mines of filter-branch, and then vigilantly avoid as many of the hazards
 listed there as reasonably possible.
@@ -145,7 +145,7 @@ OPTIONS
 --commit-filter <command>::
 	This is the filter for performing the commit.
 	If this filter is specified, it will be called instead of the
-	'git commit-tree' command, with arguments of the form
+	`git commit-tree` command, with arguments of the form
 	"<TREE_ID> [(-p <PARENT_COMMIT_ID>)...]" and the log message on
 	stdin.  The commit id is expected on stdout.
 +
@@ -156,7 +156,7 @@ have all of them as parents.
 You can use the 'map' convenience function in this filter, and other
 convenience functions, too.  For example, calling 'skip_commit "$@"'
 will leave out the current commit (but not its changes! If you want
-that, use 'git rebase' instead).
+that, use `git rebase` instead).
 +
 You can also use the `git_commit_non_empty_tree "$@"` instead of
 `git commit-tree "$@"` if you don't wish to keep commits with a single parent
@@ -187,7 +187,7 @@ to other tags will be rewritten to point to the underlying commit.
 
 --prune-empty::
 	Some filters will generate empty commits that leave the tree untouched.
-	This option instructs git-filter-branch to remove such commits if they
+	This option instructs `git-filter-branch` to remove such commits if they
 	have exactly one or zero non-pruned parents; merge commits will
 	therefore remain intact.  This option cannot be used together with
 	`--commit-filter`, though the same effect can be achieved by using the
@@ -207,7 +207,7 @@ to other tags will be rewritten to point to the underlying commit.
 
 -f::
 --force::
-	'git filter-branch' refuses to start with an existing temporary
+	`git filter-branch` refuses to start with an existing temporary
 	directory or when there are already refs starting with
 	'refs/original/', unless forced.
 
@@ -218,10 +218,10 @@ to other tags will be rewritten to point to the underlying commit.
 	trees. If '<branch>' does not exist it will be created.
 
 <rev-list options>...::
-	Arguments for 'git rev-list'.  All positive refs included by
+	Arguments for `git rev-list`.  All positive refs included by
 	these options are rewritten.  You may also specify options
 	such as `--all`, but you must use `--` to separate them from
-	the 'git filter-branch' options. Implies <<Remap_to_ancestor>>.
+	the `git filter-branch` options. Implies <<Remap_to_ancestor>>.
 
 
 [[Remap_to_ancestor]]
@@ -257,7 +257,7 @@ However, if the file is absent from the tree of some commit,
 a simple `rm filename` will fail for that tree and commit.
 Thus you may instead want to use `rm -f filename` as the script.
 
-Using `--index-filter` with 'git rm' yields a significantly faster
+Using `--index-filter` with `git rm` yields a significantly faster
 version.  Like with using `rm filename`, `git rm --cached filename`
 will fail if the file is absent from the tree of a commit.  If you
 want to "completely forget" a file, it does not matter when it entered
@@ -341,10 +341,10 @@ as their parents instead of the merge commit.
 *NOTE* the changes introduced by the commits, and which are not reverted
 by subsequent commits, will still be in the rewritten branch. If you want
 to throw out _changes_ together with the commits, you should use the
-interactive mode of 'git rebase'.
+interactive mode of `git rebase`.
 
 You can rewrite the commit log messages using `--msg-filter`.  For
-example, 'git svn-id' strings in a repository created by 'git svn' can
+example, `git svn-id` strings in a repository created by `git svn` can
 be removed this way:
 
 -------------------------------------------------------
@@ -383,7 +383,7 @@ git filter-branch --env-filter '
 
 To restrict rewriting to only part of the history, specify a revision
 range in addition to the new branch name.  The new branch name will
-point to the top-most revision that a 'git rev-list' of this range
+point to the top-most revision that a `git rev-list` of this range
 will print.
 
 Consider this history:
@@ -422,7 +422,7 @@ git filter-branch --index-filter \
 CHECKLIST FOR SHRINKING A REPOSITORY
 ------------------------------------
 
-git-filter-branch can be used to get rid of a subset of files,
+`git-filter-branch` can be used to get rid of a subset of files,
 usually with some combination of `--index-filter` and
 `--subdirectory-filter`.  People expect the resulting repository to
 be smaller than the original, but you need a few more steps to
@@ -434,7 +434,7 @@ objects until you tell it to.  First make sure that:
   can help you find renames.
 
 * You really filtered all refs: use `--tag-name-filter cat -- --all`
-  when calling git-filter-branch.
+  when calling `git-filter-branch`.
 
 Then there are two ways to get a smaller repository.  A safer way is
 to clone, that keeps your original intact.
@@ -448,30 +448,30 @@ following points instead (in this order).  This is a very destructive
 approach, so *make a backup* or go back to cloning it.  You have been
 warned.
 
-* Remove the original refs backed up by git-filter-branch: say `git
+* Remove the original refs backed up by `git-filter-branch`: say `git
   for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git
   update-ref -d`.
 
 * Expire all reflogs with `git reflog expire --expire=now --all`.
 
 * Garbage collect all unreferenced objects with `git gc --prune=now`
-  (or if your git-gc is not new enough to support arguments to
+  (or if your `git-gc` is not new enough to support arguments to
   `--prune`, use `git repack -ad; git prune` instead).
 
 [[PERFORMANCE]]
 PERFORMANCE
 -----------
 
-The performance of git-filter-branch is glacially slow; its design makes it
+The performance of `git-filter-branch` is glacially slow; its design makes it
 impossible for a backward-compatible implementation to ever be fast:
 
-* In editing files, git-filter-branch by design checks out each and
+* In editing files, `git-filter-branch` by design checks out each and
   every commit as it existed in the original repo.  If your repo has
   `10^5` files and `10^5` commits, but each commit only modifies five
-  files, then git-filter-branch will make you do `10^10` modifications,
+  files, then `git-filter-branch` will make you do `10^10` modifications,
   despite only having (at most) `5*10^5` unique blobs.
 
-* If you try and cheat and try to make git-filter-branch only work on
+* If you try and cheat and try to make `git-filter-branch` only work on
   files modified in a commit, then two things happen
 
   ** you run into problems with deletions whenever the user is simply
@@ -490,16 +490,16 @@ impossible for a backward-compatible implementation to ever be fast:
   remove some and thus can avoid checking out each file (i.e. you can
   use --index-filter), you still are passing shell snippets for your
   filters.  This means that for every commit, you have to have a
-  prepared git repo where those filters can be run.  That's a
+  prepared `git` repo where those filters can be run.  That's a
   significant setup.
 
 * Further, several additional files are created or updated per commit
-  by git-filter-branch.  Some of these are for supporting the
-  convenience functions provided by git-filter-branch (such as map()),
+  by `git-filter-branch`.  Some of these are for supporting the
+  convenience functions provided by `git-filter-branch` (such as map()),
   while others are for keeping track of internal state (but could have
   also been accessed by user filters; one of git-filter-branch's
   regression tests does so).  This essentially amounts to using the
-  filesystem as an IPC mechanism between git-filter-branch and the
+  filesystem as an IPC mechanism between `git-filter-branch` and the
   user-provided filters.  Disks tend to be a slow IPC mechanism, and
   writing these files also effectively represents a forced
   synchronization point between separate processes that we hit with
@@ -511,46 +511,46 @@ impossible for a backward-compatible implementation to ever be fast:
   of time between operating systems, but on any platform it is very
   slow relative to invoking a function.
 
-* git-filter-branch itself is written in shell, which is kind of slow.
+* `git-filter-branch` itself is written in shell, which is kind of slow.
   This is the one performance issue that could be backward-compatibly
   fixed, but compared to the above problems that are intrinsic to the
-  design of git-filter-branch, the language of the tool itself is a
+  design of `git-filter-branch`, the language of the tool itself is a
   relatively minor issue.
 
   ** Side note: Unfortunately, people tend to fixate on the
-     written-in-shell aspect and periodically ask if git-filter-branch
+     written-in-shell aspect and periodically ask if `git-filter-branch`
      could be rewritten in another language to fix the performance
      issues.  Not only does that ignore the bigger intrinsic problems
      with the design, it'd help less than you'd expect: if
-     git-filter-branch itself were not shell, then the convenience
+     `git-filter-branch` itself were not shell, then the convenience
      functions (map(), skip_commit(), etc) and the `--setup` argument
      could no longer be executed once at the beginning of the program
      but would instead need to be prepended to every user filter (and
      thus re-executed with every commit).
 
 The https://github.com/newren/git-filter-repo/[git filter-repo] tool is
-an alternative to git-filter-branch which does not suffer from these
+an alternative to `git-filter-branch` which does not suffer from these
 performance problems or the safety problems (mentioned below). For those
-with existing tooling which relies upon git-filter-branch, 'git
-filter-repo' also provides
+with existing tooling which relies upon `git-filter-branch`, `git
+filter-repo` also provides
 https://github.com/newren/git-filter-repo/blob/master/contrib/filter-repo-demos/filter-lamely[filter-lamely],
-a drop-in git-filter-branch replacement (with a few caveats).  While
+a drop-in `git-filter-branch` replacement (with a few caveats).  While
 filter-lamely suffers from all the same safety issues as
-git-filter-branch, it at least ameliorates the performance issues a
+`git-filter-branch`, it at least ameliorates the performance issues a
 little.
 
 [[SAFETY]]
 SAFETY
 ------
 
-git-filter-branch is riddled with gotchas resulting in various ways to
+`git-filter-branch` is riddled with gotchas resulting in various ways to
 easily corrupt repos or end up with a mess worse than what you started
 with:
 
 * Someone can have a set of "working and tested filters" which they
   document or provide to a coworker, who then runs them on a different
   OS where the same commands are not working/tested (some examples in
-  the git-filter-branch manpage are also affected by this).
+  the `git-filter-branch` manpage are also affected by this).
   BSD vs. GNU userland differences can really bite.  If lucky, error
   messages are spewed.  But just as likely, the commands either don't
   do the filtering requested, or silently corrupt by making some
@@ -563,7 +563,7 @@ with:
 
 * Filenames with spaces are often mishandled by shell snippets since
   they cause problems for shell pipelines.  Not everyone is familiar
-  with find -print0, xargs -0, git-ls-files -z, etc.  Even people who
+  with `find -print0`, `xargs -0`, `git-ls-files -z`, etc.  Even people who
   are familiar with these may assume such flags are not relevant
   because someone else renamed any such files in their repo back
   before the person doing the filtering joined the project.  And
@@ -590,7 +590,7 @@ with:
   problem.)
 
 * It's far too easy to accidentally mix up old and new history.  It's
-  still possible with any tool, but git-filter-branch almost
+  still possible with any tool, but `git-filter-branch` almost
   invites it.  If lucky, the only downside is users getting frustrated
   that they don't know how to shrink their repo and remove the old
   stuff.  If unlucky, they merge old and new history and end up with
@@ -612,7 +612,7 @@ with:
      need to understand that they need to rebase their changes for all
      their branches on top of new history (or delete and reclone), but
      that's only one of multiple concerns to consider.  See the
-     "DISCUSSION" section of the git filter-repo manual page for more
+     "DISCUSSION" section of the `git filter-repo` manual page for more
      details.
 
 * Annotated tags can be accidentally converted to lightweight tags,
@@ -620,16 +620,16 @@ with:
 
   ** Someone can do a history rewrite, realize they messed up, restore
      from the backups in refs/original/, and then redo their
-     git-filter-branch command.  (The backup in refs/original/ is not a
+     `git-filter-branch` command.  (The backup in refs/original/ is not a
      real backup; it dereferences tags first.)
 
-  ** Running git-filter-branch with either `--tags` or `--all` in your
+  ** Running `git-filter-branch` with either `--tags` or `--all` in your
      <rev-list options>.  In order to retain annotated tags as
      annotated, you must use `--tag-name-filter` (and must not have
      restored from refs/original/ in a previously botched rewrite).
 
 * Any commit messages that specify an encoding will become corrupted
-  by the rewrite; git-filter-branch ignores the encoding, takes the
+  by the rewrite; `git-filter-branch` ignores the encoding, takes the
   original bytes, and feeds it to commit-tree without telling it the
   proper encoding.  (This happens whether or not `--msg-filter` is
   used.)
@@ -665,12 +665,12 @@ with:
   update authors and committers, missing taggers.
 
 * If the user provides a `--tag-name-filter` that maps multiple tags to
-  the same name, no warning or error is provided; git-filter-branch
+  the same name, no warning or error is provided; `git-filter-branch`
   simply overwrites each tag in some undocumented pre-defined order
-  resulting in only one tag at the end.  (A git-filter-branch
+  resulting in only one tag at the end.  (A `git-filter-branch`
   regression test requires this surprising behavior.)
 
-Also, the poor performance of git-filter-branch often leads to safety
+Also, the poor performance of `git-filter-branch` often leads to safety
 issues:
 
 * Coming up with the correct shell snippet to do the filtering you
@@ -681,7 +681,7 @@ issues:
   circumstances (spaces in filenames, non-ascii filenames, funny
   author names or emails, invalid timezones, presence of grafts or
   replace objects, etc.), meaning they may have to wait a long time,
-  hit an error, then restart.  The performance of git-filter-branch is
+  hit an error, then restart.  The performance of `git-filter-branch` is
   so bad that this cycle is painful, reducing the time available to
   carefully re-check (to say nothing about what it does to the
   patience of the person doing the rewrite even if they do technically
diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt
index 86fb26dcea..a8e9ab914d 100644
--- a/Documentation/git-fmt-merge-msg.txt
+++ b/Documentation/git-fmt-merge-msg.txt
@@ -9,17 +9,17 @@ git-fmt-merge-msg - Produce a merge commit message
 SYNOPSIS
 --------
 [verse]
-'git fmt-merge-msg' [-m <message>] [--log[=<n>] | --no-log]
-'git fmt-merge-msg' [-m <message>] [--log[=<n>] | --no-log] -F <file>
+`git fmt-merge-msg` [-m <message>] [--log[=<n>] | --no-log]
+`git fmt-merge-msg` [-m <message>] [--log[=<n>] | --no-log] -F <file>
 
 DESCRIPTION
 -----------
 Takes the list of merged objects on stdin and produces a suitable
 commit message to be used for the merge commit, usually to be
-passed as the '<merge-message>' argument of 'git merge'.
+passed as the '<merge-message>' argument of `git merge`.
 
 This command is intended mostly for internal use by scripts
-automatically invoking 'git merge'.
+automatically invoking `git merge`.
 
 OPTIONS
 -------
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 64ff4a14f8..33fb379df4 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -8,7 +8,7 @@ git-for-each-ref - Output information on each ref
 SYNOPSIS
 --------
 [verse]
-'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
+`git for-each-ref` [--count=<count>] [--shell|--perl|--python|--tcl]
 		   [(--sort=<key>)...] [--format=<format>] [<pattern>...]
 		   [--points-at=<object>]
 		   [--merged[=<object>]] [--no-merged[=<object>]]
@@ -125,7 +125,7 @@ objecttype::
 	The type of the object (`blob`, `tree`, `commit`, `tag`).
 
 objectsize::
-	The size of the object (the same as 'git cat-file -s' reports).
+	The size of the object (the same as `git cat-file -s` reports).
 	Append `:disk` to get the size, in bytes, that the object takes up on
 	disk. See the note about on-disk sizes in the `CAVEATS` section below.
 objectname::
diff --git a/Documentation/git-for-each-repo.txt b/Documentation/git-for-each-repo.txt
index 94bd19da26..c2d6cd6629 100644
--- a/Documentation/git-for-each-repo.txt
+++ b/Documentation/git-for-each-repo.txt
@@ -9,7 +9,7 @@ git-for-each-repo - Run a Git command on a list of repositories
 SYNOPSIS
 --------
 [verse]
-'git for-each-repo' --config=<config> [--] <arguments>
+`git for-each-repo` --config=<config> [--] <arguments>
 
 
 DESCRIPTION
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index fd7c6c705b..2009a048a9 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,7 +9,7 @@ git-format-patch - Prepare patches for e-mail submission
 SYNOPSIS
 --------
 [verse]
-'git format-patch' [-k] [(-o|--output-directory) <dir> | --stdout]
+`git format-patch` [-k] [(-o|--output-directory) <dir> | --stdout]
 		   [--no-thread | --thread[=<style>]]
 		   [(--attach|--inline)[=<boundary>] | --no-attach]
 		   [-s | --signoff]
@@ -39,7 +39,7 @@ DESCRIPTION
 Prepare each commit with its "patch" in
 one "message" per commit, formatted to resemble a UNIX mailbox.
 The output of this command is convenient for e-mail submission or
-for use with 'git am'.
+for use with `git am`.
 
 A "message" generated by the command consists of three parts:
 
@@ -176,7 +176,7 @@ The default is `--no-thread`, unless the `format.thread` configuration
 is set.  If `--thread` is specified without a style, it defaults to the
 style specified by `format.thread` if any, or else `shallow`.
 +
-Beware that the default for 'git send-email' is to thread emails
+Beware that the default for `git send-email` is to thread emails
 itself.  If you want `git format-patch` to take care of threading, you
 will want to ensure that threading is disabled for `git send-email`.
 
@@ -415,7 +415,7 @@ with configuration variables.
 DISCUSSION
 ----------
 
-The patch produced by 'git format-patch' is in UNIX mailbox format,
+The patch produced by `git format-patch` is in UNIX mailbox format,
 with a fixed "magic" time stamp to indicate that the file is output
 from format-patch rather than a real mailbox, like so:
 
@@ -444,8 +444,8 @@ can save interesting patches in a UNIX mailbox and apply them with
 linkgit:git-am[1].
 
 When a patch is part of an ongoing discussion, the patch generated by
-'git format-patch' can be tweaked to take advantage of the 'git am
---scissors' feature.  After your response to the discussion comes a
+`git format-patch` can be tweaked to take advantage of the `git am
+--scissors` feature.  After your response to the discussion comes a
 line that consists solely of "`-- >8 --`" (scissors and perforation),
 followed by the patch with unnecessary header fields removed:
 
@@ -524,11 +524,11 @@ GMail
 ~~~~~
 GMail does not have any way to turn off line wrapping in the web
 interface, so it will mangle any emails that you send.  You can however
-use "git send-email" and send your patches through the GMail SMTP server, or
+use `git send-email` and send your patches through the GMail SMTP server, or
 use any IMAP email client to connect to the google IMAP server and forward
 the emails through that.
 
-For hints on using 'git send-email' to send your patches through the
+For hints on using `git send-email` to send your patches through the
 GMail SMTP server, see the EXAMPLE section of linkgit:git-send-email[1].
 
 For hints on submission using the IMAP interface, see the EXAMPLE
@@ -551,7 +551,7 @@ Install the Toggle Word Wrap add-on that is available from
 https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/
 It adds a menu entry "Enable Word Wrap" in the composer's "Options" menu
 that you can tick off. Now you can compose the message as you otherwise do
-(cut + paste, 'git format-patch' | 'git imap-send', etc), but you have to
+(cut + paste, `git format-patch` | `git imap-send`, etc), but you have to
 insert line breaks manually in any text that you type.
 
 Approach #2 (configuration)
@@ -579,7 +579,7 @@ Toggle it to make sure it is set to `false`. Also, search for
    Toggle it to make sure it is set to `false`.
 
 After that is done, you should be able to compose email as you
-otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc),
+otherwise would (cut + paste, `git format-patch` | `git imap-send`, etc),
 and the patches will not be mangled.
 
 Approach #3 (external editor)
@@ -699,7 +699,7 @@ EXAMPLES
 --------
 
 * Extract commits between revisions R1 and R2, and apply them on top of
-  the current branch using 'git am' to cherry-pick them:
+  the current branch using `git am` to `cherry-pick` them:
 +
 ------------
 $ git format-patch -k --stdout R1..R2 | git am -3 -k
diff --git a/Documentation/git-fsck-objects.txt b/Documentation/git-fsck-objects.txt
index eec4bdb600..589bb63fdc 100644
--- a/Documentation/git-fsck-objects.txt
+++ b/Documentation/git-fsck-objects.txt
@@ -9,7 +9,7 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
 SYNOPSIS
 --------
 [verse]
-'git fsck-objects' ...
+`git fsck-objects` ...
 
 DESCRIPTION
 -----------
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index d9a28e278d..048a28ee50 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -9,7 +9,7 @@ git-fsck - Verifies the connectivity and validity of the objects in the database
 SYNOPSIS
 --------
 [verse]
-'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
+`git fsck` [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
 	 [--[no-]full] [--strict] [--verbose] [--lost-found]
 	 [--[no-]dangling] [--[no-]progress] [--connectivity-only]
 	 [--[no-]name-objects] [<object>*]
@@ -23,7 +23,7 @@ OPTIONS
 <object>::
 	An object to treat as the head of an unreachability trace.
 +
-If no objects are given, 'git fsck' defaults to using the
+If no objects are given, `git fsck` defaults to using the
 index file, all SHA-1 references in `refs` namespace, and all reflogs
 (unless `--no-reflogs` is given) as heads.
 
@@ -112,7 +112,7 @@ include::config/fsck.txt[]
 DISCUSSION
 ----------
 
-git-fsck tests SHA-1 and general object sanity, and it does full tracking
+`git-fsck` tests SHA-1 and general object sanity, and it does full tracking
 of the resulting reachability and everything else. It prints out any
 corruption it finds (missing or bad objects), and if you use the
 `--unreachable` flag it will also print out objects that exist but that
@@ -124,7 +124,7 @@ Any corrupt objects you will have to find in backups or other archives
 the hopes that somebody else has the object you have corrupted).
 
 If `core.commitGraph` is true, the commit-graph file will also be inspected
-using 'git commit-graph verify'. See linkgit:git-commit-graph[1].
+using `git commit-graph verify`. See linkgit:git-commit-graph[1].
 
 Extracted Diagnostics
 ---------------------
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 9d27c3a41e..c5c71febf5 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -9,14 +9,14 @@ git-gc - Cleanup unnecessary files and optimize the local repository
 SYNOPSIS
 --------
 [verse]
-'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]
+`git gc` [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]
 
 DESCRIPTION
 -----------
 Runs a number of housekeeping tasks within the current repository,
 such as compressing file revisions (to reduce disk space and increase
 performance), removing unreachable objects which may have been
-created from prior invocations of 'git add', packing refs, pruning
+created from prior invocations of `git add`, packing refs, pruning
 reflog, rerere metadata or stale working trees. May also update ancillary
 indexes such as the commit-graph.
 
@@ -35,14 +35,14 @@ OPTIONS
 -------
 
 --aggressive::
-	Usually 'git gc' runs very quickly while providing good disk
+	Usually `git gc` runs very quickly while providing good disk
 	space utilization and performance.  This option will cause
-	'git gc' to more aggressively optimize the repository at the expense
+	`git gc` to more aggressively optimize the repository at the expense
 	of taking much more time.  The effects of this optimization are
 	mostly persistent. See the "AGGRESSIVE" section below for details.
 
 --auto::
-	With this option, 'git gc' checks whether any housekeeping is
+	With this option, `git gc` checks whether any housekeeping is
 	required; if not, it exits without performing any work.
 +
 See the `gc.auto` option in the "CONFIGURATION" section below for how
@@ -114,19 +114,19 @@ include::config/gc.txt[]
 NOTES
 -----
 
-'git gc' tries very hard not to delete objects that are referenced
+`git gc` tries very hard not to delete objects that are referenced
 anywhere in your repository. In particular, it will keep not only
 objects referenced by your current set of branches and tags, but also
 objects referenced by the index, remote-tracking branches, reflogs
 (which may reference commits in branches that were later amended or
 rewound), and anything else in the refs/* namespace. Note that a note
-(of the kind created by 'git notes') attached to an object does not
+(of the kind created by `git notes`) attached to an object does not
 contribute in keeping the object alive. If you are expecting some
 objects to be deleted and they aren't, check all of those locations
 and decide whether it makes sense in your case to remove those
 references.
 
-On the other hand, when 'git gc' runs concurrently with another process,
+On the other hand, when `git gc` runs concurrently with another process,
 there is a risk of it deleting an object that the other process is using
 but hasn't created a reference to. This may just cause the other process
 to fail or may corrupt the repository if the other process later adds a
@@ -147,7 +147,7 @@ seems to be low in practice).
 HOOKS
 -----
 
-The 'git gc --auto' command will run the 'pre-auto-gc' hook.  See
+The `git gc --auto` command will run the 'pre-auto-gc' hook.  See
 linkgit:githooks[5] for more information.
 
 
diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
index ac44d85b0b..7b7e41bf68 100644
--- a/Documentation/git-get-tar-commit-id.txt
+++ b/Documentation/git-get-tar-commit-id.txt
@@ -9,20 +9,20 @@ git-get-tar-commit-id - Extract commit ID from an archive created using git-arch
 SYNOPSIS
 --------
 [verse]
-'git get-tar-commit-id'
+`git get-tar-commit-id`
 
 
 DESCRIPTION
 -----------
 
-Read a tar archive created by 'git archive' from the standard input
+Read a tar archive created by `git archive` from the standard input
 and extract the commit ID stored in it.  It reads only the first
 1024 bytes of input, thus its runtime is not influenced by the size
 of the tar archive very much.
 
-If no commit ID is found, 'git get-tar-commit-id' quietly exists with a
+If no commit ID is found, `git get-tar-commit-id` quietly exists with a
 return code of 1.  This can happen if the archive had not been created
-using 'git archive' or if the first parameter of 'git archive' had been
+using `git archive` or if the first parameter of `git archive` had been
 a tree ID instead of a commit ID or tag.
 
 GIT
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 88047cefad..b10a3f6bb4 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -9,7 +9,7 @@ git-grep - Print lines matching a pattern
 SYNOPSIS
 --------
 [verse]
-'git grep' [-a | --text] [-I] [--textconv] [-i | --ignore-case] [-w | --word-regexp]
+`git grep` [-a | --text] [-I] [--textconv] [-i | --ignore-case] [-w | --word-regexp]
 	   [-v | --invert-match] [-h|-H] [--full-name]
 	   [-E | --extended-regexp] [-G | --basic-regexp]
 	   [-P | --perl-regexp]
@@ -66,8 +66,8 @@ grep.fullName::
 	If set to true, enable `--full-name` option by default.
 
 grep.fallbackToNoIndex::
-	If set to true, fall back to git grep `--no-index` if git grep
-	is executed outside of a git repository.  Defaults to false.
+	If set to true, fall back to `git grep --no-index` if `git grep`
+	is executed outside of a `git` repository.  Defaults to false.
 
 
 OPTIONS
@@ -191,13 +191,13 @@ providing this option will cause it to die.
 --files-without-match::
 	Instead of showing every matched line, show only the
 	names of files that contain (or do not contain) matches.
-	For better compatibility with 'git diff', `--name-only` is a
+	For better compatibility with `git diff`, `--name-only` is a
 	synonym for `--files-with-matches`.
 
 -O[<pager>]::
 --open-files-in-pager[=<pager>]::
 	Open the matching files in the pager (not the output of 'grep').
-	If the pager happens to be "less" or "vi", and the user
+	If the pager happens to be `less` or `vi`, and the user
 	specified only one pattern, the first file is positioned at
 	the first match automatically. The `pager` argument is
 	optional; if specified, it must be stuck to the option
diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
index c9d7e96214..ff66c5b1d0 100644
--- a/Documentation/git-gui.txt
+++ b/Documentation/git-gui.txt
@@ -8,23 +8,23 @@ git-gui - A portable graphical interface to Git
 SYNOPSIS
 --------
 [verse]
-'git gui' [<command>] [arguments]
+`git gui` [<command>] [arguments]
 
 DESCRIPTION
 -----------
-A Tcl/Tk based graphical user interface to Git.  'git gui' focuses
+A Tcl/Tk based graphical user interface to Git.  `git gui` focuses
 on allowing users to make changes to their repository by making
 new commits, amending existing ones, creating branches, performing
 local merges, and fetching/pushing to remote repositories.
 
-Unlike 'gitk', 'git gui' focuses on commit generation
+Unlike `gitk`, `git gui` focuses on commit generation
 and single file annotation and does not show project history.
-It does however supply menu actions to start a 'gitk' session from
-within 'git gui'.
+It does however supply menu actions to start a `gitk` session from
+within `git gui`.
 
-'git gui' is known to work on all popular UNIX systems, Mac OS X,
+`git gui` is known to work on all popular UNIX systems, Mac OS X,
 and Windows (under both Cygwin and MSYS).  To the extent possible
-OS specific user interface guidelines are followed, making 'git gui'
+OS specific user interface guidelines are followed, making `git gui`
 a fairly native interface for users.
 
 COMMANDS
@@ -39,13 +39,13 @@ browser::
 	browser are opened in the blame viewer.
 
 citool::
-	Start 'git gui' and arrange to make exactly one commit before
+	Start `git gui` and arrange to make exactly one commit before
 	exiting and returning to the shell.  The interface is limited
 	to only commit actions, slightly reducing the application's
 	startup time and simplifying the menubar.
 
 version::
-	Display the currently running version of 'git gui'.
+	Display the currently running version of `git gui`.
 
 
 Examples
@@ -103,16 +103,16 @@ SEE ALSO
 --------
 linkgit:gitk[1]::
 	The Git repository browser.  Shows branches, commit history
-	and file differences.  gitk is the utility started by
+	and file differences.  `gitk` is the utility started by
 	'git gui''s Repository Visualize actions.
 
 Other
 -----
-'git gui' is actually maintained as an independent project, but stable
+`git gui` is actually maintained as an independent project, but stable
 versions are distributed as part of the Git suite for the convenience
 of end users.
 
-The official repository of the 'git gui' project can be found at:
+The official repository of the `git gui` project can be found at:
 
   https://github.com/prati0100/git-gui.git/
 
diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
index df9e2c58bd..15c2945345 100644
--- a/Documentation/git-hash-object.txt
+++ b/Documentation/git-hash-object.txt
@@ -9,8 +9,8 @@ git-hash-object - Compute object ID and optionally creates a blob from a file
 SYNOPSIS
 --------
 [verse]
-'git hash-object' [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin [--literally]] [--] <file>...
-'git hash-object' [-t <type>] [-w] --stdin-paths [--no-filters]
+`git hash-object` [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin [--literally]] [--] <file>...
+`git hash-object` [-t <type>] [-w] --stdin-paths [--no-filters]
 
 DESCRIPTION
 -----------
@@ -54,7 +54,7 @@ OPTIONS
 
 --literally::
 	Allow `--stdin` to hash any garbage into a loose object which might not
-	otherwise pass standard object parsing or git-fsck checks. Useful for
+	otherwise pass standard object parsing or `git-fsck` checks. Useful for
 	stress-testing Git itself or reproducing characteristics of corrupt or
 	bogus objects encountered in the wild.
 
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index 392f7be6fa..2d5660f47a 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -8,13 +8,13 @@ git-help - Display help information about Git
 SYNOPSIS
 --------
 [verse]
-'git help' [-a|--all [--[no-]verbose]] [-g|--guides]
+`git help` [-a|--all [--[no-]verbose]] [-g|--guides]
 	   [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
 
 DESCRIPTION
 -----------
 
-With no options and no COMMAND or GUIDE given, the synopsis of the 'git'
+With no options and no COMMAND or GUIDE given, the synopsis of the `git`
 command and a list of the most commonly used Git commands are printed
 on the standard output.
 
@@ -29,7 +29,7 @@ guide is brought up. The 'man' program is used by default for this
 purpose, but this can be overridden by other options or configuration
 variables.
 
-If an alias is given, git shows the definition of the alias on
+If an alias is given, `git` shows the definition of the alias on
 standard output. To get the manual page for the aliased command, use
 `git COMMAND --help`.
 
@@ -38,7 +38,7 @@ former is internally converted into the latter.
 
 To display the linkgit:git[1] man page, use `git help git`.
 
-This page can be displayed with 'git help help' or `git help --help`
+This page can be displayed with `git help help` or `git help --help`
 
 OPTIONS
 -------
@@ -83,8 +83,8 @@ other display programs (see below).
 +
 The web browser can be specified using the configuration variable
 `help.browser`, or `web.browser` if the former is not set. If none of
-these config variables is set, the 'git web{litdd}browse' helper script
-(called by 'git help') will pick a suitable default. See
+these config variables is set, the `git web--browse` helper script
+(called by `git help`) will pick a suitable default. See
 linkgit:git-web{litdd}browse[1] for more information about this.
 
 CONFIGURATION VARIABLES
@@ -95,7 +95,7 @@ help.format
 
 If no command-line option is passed, the `help.format` configuration
 variable will be checked. The following values are supported for this
-variable; they make 'git help' behave as their corresponding command-
+variable; they make `git help` behave as their corresponding command-
 line option:
 
 * "man" corresponds to `-m`|`--man`,
@@ -150,7 +150,7 @@ man.<tool>.path
 You can explicitly provide a full path to your preferred man viewer by
 setting the configuration variable `man.<tool>.path`. For example, you
 can configure the absolute path to konqueror by setting
-`man.konqueror.path`. Otherwise, 'git help' assumes the tool is
+`man.konqueror.path`. Otherwise, `git help` assumes the tool is
 available in PATH.
 
 man.<tool>.cmd
@@ -185,7 +185,7 @@ the following:
 		cmd = A_PATH_TO/konqueror
 ------------------------------------------------
 
-Note about git config --global
+Note about `git config --global`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Note that all these configuration variables should probably be set
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 558966aa83..c97c10ba09 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -8,7 +8,7 @@ git-http-backend - Server side implementation of Git over HTTP
 SYNOPSIS
 --------
 [verse]
-'git http-backend'
+`git http-backend`
 
 DESCRIPTION
 -----------
@@ -19,15 +19,15 @@ and the backwards-compatible dumb HTTP protocol, as well as clients
 pushing using the smart HTTP protocol.
 
 It verifies that the directory has the magic file
-"git-daemon-export-ok", and it will refuse to export any Git directory
+`git-daemon-export-ok`, and it will refuse to export any Git directory
 that hasn't explicitly been marked for export this way (unless the
 `GIT_HTTP_EXPORT_ALL` environmental variable is set).
 
 By default, only the `upload-pack` service is enabled, which serves
-'git fetch-pack' and 'git ls-remote' clients, which are invoked from
-'git fetch', 'git pull', and 'git clone'.  If the client is authenticated,
-the `receive-pack` service is enabled, which serves 'git send-pack'
-clients, which is invoked from 'git push'.
+`git fetch-pack` and `git ls-remote` clients, which are invoked from
+`git fetch`, `git pull`, and `git clone`.  If the client is authenticated,
+the `receive-pack` service is enabled, which serves `git send-pack`
+clients, which is invoked from `git push`.
 
 SERVICES
 --------
@@ -43,12 +43,12 @@ http.getanyfile::
 	by setting this configuration item to `false`.
 
 http.uploadpack::
-	This serves 'git fetch-pack' and 'git ls-remote' clients.
+	This serves `git fetch-pack` and `git ls-remote` clients.
 	It is enabled by default, but a repository can disable it
 	by setting this configuration item to `false`.
 
 http.receivepack::
-	This serves 'git send-pack' clients, allowing push.  It is
+	This serves `git send-pack` clients, allowing push.  It is
 	disabled by default for anonymous users, and enabled by
 	default for users authenticated by the web server.  It can be
 	disabled by setting this item to `false`, or enabled for all
@@ -56,11 +56,11 @@ http.receivepack::
 
 URL TRANSLATION
 ---------------
-To determine the location of the repository on disk, 'git http-backend'
+To determine the location of the repository on disk, `git http-backend`
 concatenates the environment variables PATH_INFO, which is set
 automatically by the web server, and GIT_PROJECT_ROOT, which must be set
 manually in the web server configuration.  If GIT_PROJECT_ROOT is not
-set, 'git http-backend' reads PATH_TRANSLATED, which is also set
+set, `git http-backend` reads PATH_TRANSLATED, which is also set
 automatically by the web server.
 
 EXAMPLES
@@ -135,9 +135,9 @@ directive around the repository, or one of its parent directories:
 </Location>
 ----------------------------------------------------------------
 +
-To serve gitweb at the same url, use a ScriptAliasMatch to only
-those URLs that 'git http-backend' can handle, and forward the
-rest to gitweb:
+To serve `gitweb` at the same url, use a ScriptAliasMatch to only
+those URLs that `git http-backend` can handle, and forward the
+rest to `gitweb`:
 +
 ----------------------------------------------------------------
 ScriptAliasMatch \
@@ -174,7 +174,7 @@ AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1
 ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
 ----------------------------------------------------------------
 +
-This can be combined with the gitweb configuration:
+This can be combined with the `gitweb` configuration:
 +
 ----------------------------------------------------------------
 SetEnv GIT_PROJECT_ROOT /var/www/git
@@ -241,7 +241,7 @@ $HTTP["url"] =~ "^/git/private" {
 
 ENVIRONMENT
 -----------
-'git http-backend' relies upon the `CGI` environment variables set
+`git http-backend` relies upon the `CGI` environment variables set
 by the invoking web server, including:
 
 * PATH_INFO (if GIT_PROJECT_ROOT is set, otherwise PATH_TRANSLATED)
@@ -252,12 +252,12 @@ by the invoking web server, including:
 * REQUEST_METHOD
 
 The `GIT_HTTP_EXPORT_ALL` environmental variable may be passed to
-'git-http-backend' to bypass the check for the "git-daemon-export-ok"
+`git-http-backend` to bypass the check for the `git-daemon-export-ok`
 file in each repository before allowing export of that repository.
 
 The `GIT_HTTP_MAX_REQUEST_BUFFER` environment variable (or the
 `http.maxRequestBuffer` config variable) may be set to change the
-largest ref negotiation request that git will handle during a fetch; any
+largest ref negotiation request that `git` will handle during a fetch; any
 fetch requiring a larger buffer will not succeed.  This value should not
 normally need to be changed, but may be helpful if you are fetching from
 a repository with an extremely large number of refs.  The value can be
@@ -266,11 +266,11 @@ specified with a unit (e.g., `100M` for 100 megabytes). The default is
 
 The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and
 GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}',
-ensuring that any reflogs created by 'git-receive-pack' contain some
+ensuring that any reflogs created by `git-receive-pack` contain some
 identifying information of the remote user who performed the push.
 
 All `CGI` environment variables are available to each of the hooks
-invoked by the 'git-receive-pack'.
+invoked by the `git-receive-pack`.
 
 GIT
 ---
diff --git a/Documentation/git-http-fetch.txt b/Documentation/git-http-fetch.txt
index 969e553e4a..87028e3312 100644
--- a/Documentation/git-http-fetch.txt
+++ b/Documentation/git-http-fetch.txt
@@ -9,7 +9,7 @@ git-http-fetch - Download from a remote Git repository via HTTP
 SYNOPSIS
 --------
 [verse]
-'git http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin | --packfile=<hash> | <commit>] <url>
+`git http-fetch` [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin | --packfile=<hash> | <commit>] <url>
 
 DESCRIPTION
 -----------
@@ -36,14 +36,14 @@ commit-id::
 
 --stdin::
 	Instead of a commit id on the command line (which is not expected in this
-	case), 'git http-fetch' expects lines on stdin in the format
+	case), `git http-fetch` expects lines on stdin in the format
 
 		<commit-id>['\t'<filename-as-in--w>]
 
 --packfile=<hash>::
 	For internal use only. Instead of a commit id on the command
 	line (which is not expected in
-	this case), 'git http-fetch' fetches the packfile directly at the given
+	this case), `git http-fetch` fetches the packfile directly at the given
 	URL and uses index-pack to generate corresponding .idx and .keep files.
 	The hash is used to determine the name of the temporary file and is
 	arbitrary. The output of index-pack is printed to stdout. Requires
diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt
index 7ba8ea2383..85c564c412 100644
--- a/Documentation/git-http-push.txt
+++ b/Documentation/git-http-push.txt
@@ -9,7 +9,7 @@ git-http-push - Push objects over HTTP/DAV to another repository
 SYNOPSIS
 --------
 [verse]
-'git http-push' [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>...]
+`git http-push` [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>...]
 
 DESCRIPTION
 -----------
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index 63cf498ce9..68b1fb19e2 100644
--- a/Documentation/git-imap-send.txt
+++ b/Documentation/git-imap-send.txt
@@ -9,12 +9,12 @@ git-imap-send - Send a collection of patches from stdin to an IMAP folder
 SYNOPSIS
 --------
 [verse]
-'git imap-send' [-v] [-q] [--[no-]curl]
+`git imap-send` [-v] [-q] [--[no-]curl]
 
 
 DESCRIPTION
 -----------
-This command uploads a mailbox generated with 'git format-patch'
+This command uploads a mailbox generated with `git format-patch`
 into an IMAP drafts folder.  This allows patches to be sent as
 other email is when using mail clients that cannot read mailbox
 files directly. The command also works with any general mailbox
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
index bde1cf4a5c..fa859f759d 100644
--- a/Documentation/git-index-pack.txt
+++ b/Documentation/git-index-pack.txt
@@ -9,8 +9,8 @@ git-index-pack - Build pack index file for an existing packed archive
 SYNOPSIS
 --------
 [verse]
-'git index-pack' [-v] [-o <index-file>] [--[no-]rev-index] <pack-file>
-'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
+`git index-pack` [-v] [-o <index-file>] [--[no-]rev-index] <pack-file>
+`git index-pack` --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
 		  [--[no-]rev-index] [<pack-file>]
 
 
@@ -51,7 +51,7 @@ OPTIONS
 	a default name determined from the pack content.  If
 	<pack-file> is not specified consider using `--keep` to
 	prevent a race condition between this process and
-	'git repack'.
+	`git repack`.
 
 --fix-thin::
 	Fix a "thin" pack produced by `git pack-objects --thin` (see
@@ -63,7 +63,7 @@ OPTIONS
 	Before moving the index into its final destination
 	create an empty .keep file for the associated pack file.
 	This option is usually necessary with `--stdin` to prevent a
-	simultaneous 'git repack' process from deleting
+	simultaneous `git repack` process from deleting
 	the newly constructed pack and index before refs can be
 	updated to use objects contained in the pack.
 
@@ -123,7 +123,7 @@ Once the index has been created, the hash that goes into the name of
 the pack/idx file is printed to stdout. If `--stdin` was
 also used then this is prefixed by either "pack\t", or "keep\t" if a
 new .keep file was successfully created. This is useful to remove a
-.keep file used as a lock to prevent the race with 'git repack'
+.keep file used as a lock to prevent the race with `git repack`
 mentioned above.
 
 GIT
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index 648a6cd78a..b62407333b 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -9,7 +9,7 @@ git-init-db - Creates an empty Git repository
 SYNOPSIS
 --------
 [verse]
-'git init-db' [-q | --quiet] [--bare] [--template=<template_directory>] [--separate-git-dir <git dir>] [--shared[=<permissions>]]
+`git init-db` [-q | --quiet] [--bare] [--template=<template_directory>] [--separate-git-dir <git dir>] [--shared[=<permissions>]]
 
 
 DESCRIPTION
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 47d61fc505..2ee178a81c 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -9,7 +9,7 @@ git-init - Create an empty Git repository or reinitialize an existing one
 SYNOPSIS
 --------
 [verse]
-'git init' [-q | --quiet] [--bare] [--template=<template_directory>]
+`git init` [-q | --quiet] [--bare] [--template=<template_directory>]
 	  [--separate-git-dir <git dir>] [--object-format=<format>]
 	  [-b <branch-name> | --initial-branch=<branch-name>]
 	  [--shared[=<permissions>]] [directory]
@@ -32,9 +32,9 @@ If the object storage directory is specified via the
 are created underneath - otherwise the default `$GIT_DIR/objects`
 directory is used.
 
-Running 'git init' in an existing repository is safe. It will not
+Running `git init` in an existing repository is safe. It will not
 overwrite things that are already there. The primary reason for
-rerunning 'git init' is to pick up newly added templates (or to move
+rerunning `git init` is to pick up newly added templates (or to move
 the repository to another place if `--separate-git-dir` is given).
 
 OPTIONS
@@ -99,7 +99,7 @@ specified.
 
 'group' (or 'true')::
 
-Make the repository group-writable, (and g+sx, since the git group may be not
+Make the repository group-writable, (and g+sx, since the `git` group may be not
 the primary group of all users). This is used to loosen the permissions of an
 otherwise safe umask(2) value. Note that the umask still applies to the other
 permission bits (e.g. if umask is '0022', using 'group' will not remove read
diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
index a54fe4401b..dfbd3a40ce 100644
--- a/Documentation/git-instaweb.txt
+++ b/Documentation/git-instaweb.txt
@@ -8,9 +8,9 @@ git-instaweb - Instantly browse your working repository in gitweb
 SYNOPSIS
 --------
 [verse]
-'git instaweb' [--local] [--httpd=<httpd>] [--port=<port>]
+`git instaweb` [--local] [--httpd=<httpd>] [--port=<port>]
                [--browser=<browser>]
-'git instaweb' [--start] [--stop] [--restart]
+`git instaweb` [--start] [--stop] [--restart]
 
 DESCRIPTION
 -----------
@@ -44,9 +44,9 @@ OPTIONS
 
 -b::
 --browser::
-	The web browser that should be used to view the gitweb
-	page. This will be passed to the 'git web{litdd}browse' helper
-	script along with the URL of the gitweb instance. See
+	The web browser that should be used to view the `gitweb`
+	page. This will be passed to the `git web--browse` helper
+	script along with the URL of the `gitweb` instance. See
 	linkgit:git-web{litdd}browse[1] for more information about this. If
 	the script fails, the URL will be printed to stdout.
 
diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt
index 1160807e0d..b687701104 100644
--- a/Documentation/git-interpret-trailers.txt
+++ b/Documentation/git-interpret-trailers.txt
@@ -8,8 +8,8 @@ git-interpret-trailers - Add or parse structured information in commit messages
 SYNOPSIS
 --------
 [verse]
-'git interpret-trailers' [<options>] [(--trailer <token>[(=|:)<value>])...] [<file>...]
-'git interpret-trailers' [<options>] [--parse] [<file>...]
+`git interpret-trailers` [<options>] [(--trailer <token>[(=|:)<value>])...] [<file>...]
+`git interpret-trailers` [<options>] [--parse] [<file>...]
 
 DESCRIPTION
 -----------
@@ -138,7 +138,7 @@ trailer.separators::
 	This option tells which characters are recognized as trailer
 	separators. By default only ':' is recognized as a trailer
 	separator, except that '=' is always accepted on the command
-	line for compatibility with other git commands.
+	line for compatibility with other `git` commands.
 +
 The first character given by this option will be the default character
 used when another separator is not specified in the config for this
@@ -358,8 +358,8 @@ See-also: fe3187489d69c4 (subject of related commit)
 * Configure a commit template with some trailers with empty values
   (using sed to show and keep the trailing spaces at the end of the
   trailers), then configure a commit-msg hook that uses
-  'git interpret-trailers' to remove trailers with empty values and
-  to add a 'git-version' trailer:
+  `git interpret-trailers` to remove trailers with empty values and
+  to add a `git-version` trailer:
 +
 ------------
 $ sed -e 's/ Z$/ /' >commit_template.txt <<EOF
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index b306dced1c..a6b3bc1611 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -9,7 +9,7 @@ git-log - Show commit logs
 SYNOPSIS
 --------
 [verse]
-'git log' [<options>] [<revision range>] [[--] <path>...]
+`git log` [<options>] [<revision range>] [[--] <path>...]
 
 DESCRIPTION
 -----------
@@ -133,14 +133,14 @@ EXAMPLES
 
 `git log --since="2 weeks ago" -- gitk`::
 
-	Show the changes during the last two weeks to the file 'gitk'.
+	Show the changes during the last two weeks to the file `gitk`.
 	The `--` is necessary to avoid confusion with the *branch* named
-	'gitk'
+	`gitk`
 
 `git log --name-status release..test`::
 
-	Show the commits that are in the "test" branch but not yet
-	in the "release" branch, along with the list of paths
+	Show the commits that are in the `test` branch but not yet
+	in the `release` branch, along with the list of paths
 	each commit modifies.
 
 `git log --follow builtin/rev-list.c`::
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index d27a33eb22..ee435024da 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -9,7 +9,7 @@ git-ls-files - Show information about files in the index and the working tree
 SYNOPSIS
 --------
 [verse]
-'git ls-files' [-z] [-t] [-v] [-f]
+`git ls-files` [-z] [-t] [-v] [-f]
 		(--[cached|deleted|others|ignored|stage|unmerged|killed|modified])*
 		(-[c|d|o|i|s|u|k|m])*
 		[--eol]
@@ -196,15 +196,15 @@ followed by the  ("attr/<eolattr>").
 
 OUTPUT
 ------
-'git ls-files' just outputs the filenames unless `--stage` is specified in
+`git ls-files` just outputs the filenames unless `--stage` is specified in
 which case it outputs:
 
         [<tag> ]<mode> <object> <stage> <file>
 
-'git ls-files --eol' will show
+`git ls-files --eol` will show
 	i/<eolinfo><SPACES>w/<eolinfo><SPACES>attr/<eolattr><SPACE*><TAB><file>
 
-'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine
+`git ls-files --unmerged` and `git ls-files --stage` can be used to examine
 detailed information on unmerged paths.
 
 For an unmerged path, instead of recording a single mode/SHA-1 pair,
@@ -222,7 +222,7 @@ verbatim and the line is terminated by a NUL byte.
 EXCLUDE PATTERNS
 ----------------
 
-'git ls-files' can use a list of "exclude patterns" when
+`git ls-files` can use a list of "exclude patterns" when
 traversing the directory tree and finding files to show when the
 flags `--others` or `--ignored` are specified.  linkgit:gitignore[5]
 specifies the format of exclude patterns.
@@ -238,7 +238,7 @@ These exclude patterns come from these places, in order:
      in the same order they appear in the file.
 
   3. The command-line flag `--exclude-per-directory=<name>` specifies
-     a name of the file in each directory 'git ls-files'
+     a name of the file in each directory `git ls-files`
      examines, normally `.gitignore`.  Files in deeper
      directories take precedence.  Patterns are ordered in the
      same order they appear in the files.
diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
index dbe0c69298..cc1525f487 100644
--- a/Documentation/git-ls-remote.txt
+++ b/Documentation/git-ls-remote.txt
@@ -9,7 +9,7 @@ git-ls-remote - List references in a remote repository
 SYNOPSIS
 --------
 [verse]
-'git ls-remote' [--heads] [--tags] [--refs] [--upload-pack=<exec>]
+`git ls-remote` [--heads] [--tags] [--refs] [--upload-pack=<exec>]
 	      [-q | --quiet] [--exit-code] [--get-url] [--sort=<key>]
 	      [--symref] [<repository> [<refs>...]]
 
@@ -30,7 +30,7 @@ OPTIONS
 	both, references stored in refs/heads and refs/tags are
 	displayed.  Note that `git ls-remote -h` used without
 	anything else on the command line gives help, consistent
-	with other git subcommands.
+	with other `git` subcommands.
 
 --refs::
 	Do not show peeled tags or pseudorefs like `HEAD` in the output.
@@ -40,7 +40,7 @@ OPTIONS
 	Do not print remote URL to stderr.
 
 --upload-pack=<exec>::
-	Specify the full path of 'git-upload-pack' on the remote
+	Specify the full path of `git-upload-pack` on the remote
 	host. This allows listing references from repositories accessed via
 	SSH and where the SSH daemon does not use the PATH configured by the
 	user.
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index 6ed9030c1e..82c802d918 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -9,7 +9,7 @@ git-ls-tree - List the contents of a tree object
 SYNOPSIS
 --------
 [verse]
-'git ls-tree' [-d] [-r] [-t] [-l] [-z]
+`git ls-tree` [-d] [-r] [-t] [-l] [-z]
 	    [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=<n>]]
 	    <tree-ish> [<path>...]
 
@@ -25,8 +25,8 @@ in the current working directory.  Note that:
 
  - the behaviour is similar to that of "/bin/ls" in that the '<path>' is
    taken as relative to the current working directory.  E.g. when you are
-   in a directory 'sub' that has a directory 'dir', you can run 'git
-   ls-tree -r HEAD dir' to list the contents of the tree (that is
+   in a directory 'sub' that has a directory 'dir', you can run `git
+   ls-tree -r HEAD dir` to list the contents of the tree (that is
    `sub/dir` in `HEAD`).  You don't want to give a tree that is not at the
    root level (e.g. `git ls-tree -r HEAD:sub dir`) in this case, as that
    would result in asking for `sub/sub/dir` in the `HEAD` commit.
@@ -85,7 +85,7 @@ Output Format
         <mode> SP <type> SP <object> TAB <file>
 
 This output format is compatible with what `--index-info --stdin` of
-'git update-index' expects.
+`git update-index` expects.
 
 When the `-l` option is used, format changes to
 
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index c54feb665b..b47e92ee57 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -9,7 +9,7 @@ git-mailinfo - Extracts patch and authorship from a single e-mail message
 SYNOPSIS
 --------
 [verse]
-'git mailinfo' [-k|-b] [-u | --encoding=<encoding> | -n] [--[no-]scissors] <msg> <patch>
+`git mailinfo` [-k|-b] [-u | --encoding=<encoding> | -n] [--[no-]scissors] <msg> <patch>
 
 
 DESCRIPTION
@@ -17,7 +17,7 @@ DESCRIPTION
 Reads a single e-mail message from the standard input, and
 writes the commit log message in <msg> file, and the patches in
 <patch> file.  The author name, e-mail and e-mail subject are
-written out to the standard output to be used by 'git am'
+written out to the standard output to be used by `git am`
 to create a commit.  It is usually not necessary to use this
 command directly.  See linkgit:git-am[1] instead.
 
@@ -28,7 +28,7 @@ OPTIONS
 	Usually the program removes email cruft from the Subject:
 	header line to extract the title line for the commit log
 	message.  This option prevents this munging, and is most
-	useful when used to read back 'git format-patch -k' output.
+	useful when used to read back `git format-patch -k` output.
 +
 Specifically, the following are removed until none of them remain:
 +
diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt
index 6e357716ec..151c4f96be 100644
--- a/Documentation/git-mailsplit.txt
+++ b/Documentation/git-mailsplit.txt
@@ -8,7 +8,7 @@ git-mailsplit - Simple UNIX mbox splitter program
 SYNOPSIS
 --------
 [verse]
-'git mailsplit' [-b] [-f<nn>] [-d<prec>] [--keep-cr] [--mboxrd]
+`git mailsplit` [-b] [-f<nn>] [-d<prec>] [--keep-cr] [--mboxrd]
 		-o<directory> [--] [(<mbox>|<Maildir>)...]
 
 DESCRIPTION
diff --git a/Documentation/git-maintenance.txt b/Documentation/git-maintenance.txt
index 80ddd33ceb..c69b3cec4f 100644
--- a/Documentation/git-maintenance.txt
+++ b/Documentation/git-maintenance.txt
@@ -9,7 +9,7 @@ git-maintenance - Run tasks to optimize Git repository data
 SYNOPSIS
 --------
 [verse]
-'git maintenance' run [<options>]
+`git maintenance` run [<options>]
 
 
 DESCRIPTION
diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt
index 2d944e0851..323bc045bf 100644
--- a/Documentation/git-merge-base.txt
+++ b/Documentation/git-merge-base.txt
@@ -9,16 +9,16 @@ git-merge-base - Find as good common ancestors as possible for a merge
 SYNOPSIS
 ------