manpages: italicize git command names (which were in teletype font)

The names of git commands are not meant to be entered at the
commandline; they are just names. So we render them in italics,
as is usual for command names in manpages.

Using

	doit () {
	  perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }'
	}
	for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \
	        merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt
	do
	  doit <"$i" >"$i+" && mv "$i+" "$i"
	done
	git diff

.

Signed-off-by: Jonathan Nieder <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

Documentation/config.txt

@@ -63,7 +63,7 @@ The values following the equals sign in variable assign are all either
 a string, an integer, or a boolean.  Boolean values may be given as yes/no,
 0/1 or true/false.  Case is not significant in boolean values, when
 converting value to the canonical form using '--bool' type specifier;
-`git-config` will ensure that the output is "true" or "false".
+'git-config' will ensure that the output is "true" or "false".
 
 String values may be entirely or partially enclosed in double quotes.
 You need to enclose variable value in double quotes if you want to
@@ -356,8 +356,8 @@ core.pager::
 
 core.whitespace::
 	A comma separated list of common whitespace problems to
-	notice.  `git-diff` will use `color.diff.whitespace` to
-	highlight them, and `git-apply --whitespace=error` will
+	notice.  'git-diff' will use `color.diff.whitespace` to
+	highlight them, and 'git-apply --whitespace=error' will
 	consider them as errors:
 +
 * `trailing-space` treats trailing whitespaces at the end of the line
@@ -396,11 +396,11 @@ it will be treated as a shell command.  For example, defining
 "gitk --all --not ORIG_HEAD".
 
 apply.whitespace::
-	Tells `git-apply` how to handle whitespaces, in the same way
+	Tells 'git-apply' how to handle whitespaces, in the same way
 	as the '--whitespace' option. See linkgit:git-apply[1].
 
 branch.autosetupmerge::
-	Tells `git-branch` and `git-checkout` to setup new branches
+	Tells 'git-branch' and 'git-checkout' to setup new branches
 	so that linkgit:git-pull[1] will appropriately merge from the
 	starting point branch. Note that even if this option is not set,
 	this behavior can be chosen per-branch using the `--track`
@@ -411,7 +411,7 @@ branch.autosetupmerge::
 	branch. This option defaults to true.
 
 branch.autosetuprebase::
-	When a new branch is created with `git-branch` or `git-checkout`
+	When a new branch is created with 'git-branch' or 'git-checkout'
 	that tracks another branch, this variable tells git to set
 	up pull to rebase instead of merge (see "branch.<name>.rebase").
 	When `never`, rebase is never automatically set to true.
@@ -426,20 +426,20 @@ branch.autosetuprebase::
 	This option defaults to never.
 
 branch.<name>.remote::
-	When in branch <name>, it tells `git-fetch` which remote to fetch.
-	If this option is not given, `git-fetch` defaults to remote "origin".
+	When in branch <name>, it tells 'git-fetch' which remote to fetch.
+	If this option is not given, 'git-fetch' defaults to remote "origin".
 
 branch.<name>.merge::
-	When in branch <name>, it tells `git-fetch` the default
+	When in branch <name>, it tells 'git-fetch' the default
 	refspec to be marked for merging in FETCH_HEAD. The value is
 	handled like the remote part of a refspec, and must match a
 	ref which is fetched from the remote given by
 	"branch.<name>.remote".
-	The merge information is used by `git-pull` (which at first calls
-	`git-fetch`) to lookup the default branch for merging. Without
-	this option, `git-pull` defaults to merge the first refspec fetched.
+	The merge information is used by 'git-pull' (which at first calls
+	'git-fetch') to lookup the default branch for merging. Without
+	this option, 'git-pull' defaults to merge the first refspec fetched.
 	Specify multiple values to get an octopus merge.
-	If you wish to setup `git-pull` so that it merges into <name> from
+	If you wish to setup 'git-pull' so that it merges into <name> from
 	another branch in the local repository, you can point
 	branch.<name>.merge to the desired branch, and use the special setting
 	`.` (a period) for branch.<name>.remote.
@@ -513,7 +513,7 @@ color.interactive::
 	colors only when the output is to the terminal. Defaults to false.
 
 color.interactive.<slot>::
-	Use customized color for `git-add --interactive`
+	Use customized color for 'git-add --interactive'
 	output. `<slot>` may be `prompt`, `header`, or `help`, for
 	three distinct types of normal output from interactive
 	programs.  The values of these variables may be specified as
@@ -550,14 +550,14 @@ color.ui::
 	take precedence over this setting. Defaults to false.
 
 diff.autorefreshindex::
-	When using `git-diff` to compare with work tree
+	When using 'git-diff' to compare with work tree
 	files, do not consider stat-only change as changed.
 	Instead, silently run `git update-index --refresh` to
 	update the cached stat information for paths whose
 	contents in the work tree match the contents in the
 	index.  This option defaults to true.  Note that this
-	affects only `git-diff` Porcelain, and not lower level
-	`diff` commands, such as `git-diff-files`.
+	affects only 'git-diff' Porcelain, and not lower level
+	`diff` commands, such as 'git-diff-files'.
 
 diff.external::
 	If this config variable is set, diff generation is not
@@ -625,37 +625,37 @@ gc.autopacklimit::
 	default	value is 50.  Setting this to 0 disables it.
 
 gc.packrefs::
-	`git-gc` does not run `git pack-refs` in a bare repository by
+	'git-gc' does not run `git pack-refs` in a bare repository by
 	default so that older dumb-transport clients can still fetch
-	from the repository.  Setting this to `true` lets `git-gc`
+	from the repository.  Setting this to `true` lets 'git-gc'
 	to run `git pack-refs`.  Setting this to `false` tells
-	`git-gc` never to run `git pack-refs`. The default setting is
+	'git-gc' never to run `git pack-refs`. The default setting is
 	`notbare`. Enable it only when you know you do not have to
 	support such clients.  The default setting will change to `true`
 	at some stage, and setting this to `false` will continue to
-	prevent `git pack-refs` from being run from `git-gc`.
+	prevent `git pack-refs` from being run from 'git-gc'.
 
 gc.pruneexpire::
-	When `git-gc` is run, it will call `prune --expire 2.weeks.ago`.
+	When 'git-gc' is run, it will call `prune --expire 2.weeks.ago`.
 	Override the grace period with this config variable.
 
 gc.reflogexpire::
-	`git-reflog expire` removes reflog entries older than
+	'git-reflog expire' removes reflog entries older than
 	this time; defaults to 90 days.
 
 gc.reflogexpireunreachable::
-	`git-reflog expire` removes reflog entries older than
+	'git-reflog expire' removes reflog entries older than
 	this time and are not reachable from the current tip;
 	defaults to 30 days.
 
 gc.rerereresolved::
 	Records of conflicted merge you resolved earlier are
-	kept for this many days when `git-rerere gc` is run.
+	kept for this many days when 'git-rerere gc' is run.
 	The default is 60 days.  See linkgit:git-rerere[1].
 
 gc.rerereunresolved::
 	Records of conflicted merge you have not resolved are
-	kept for this many days when `git-rerere gc` is run.
+	kept for this many days when 'git-rerere gc' is run.
 	The default is 15 days.  See linkgit:git-rerere[1].
 
 rerere.enabled::
@@ -821,7 +821,7 @@ i18n.commitEncoding::
 
 i18n.logOutputEncoding::
 	Character encoding the commit messages are converted to when
-	running `git-log` and friends.
+	running 'git-log' and friends.
 
 instaweb.browser::
 	Specify the program that will be used to browse your working

Documentation/fetch-options.txt

@@ -21,7 +21,7 @@
 
 -f::
 --force::
-	When `git-fetch` is used with `<rbranch>:<lbranch>`
+	When 'git-fetch' is used with `<rbranch>:<lbranch>`
 	refspec, it refuses to update the local branch
 	`<lbranch>` unless the remote branch `<rbranch>` it
 	fetches is a descendant of `<lbranch>`.  This option
@@ -53,10 +53,10 @@ endif::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.
 

Documentation/git-am.txt

@@ -35,11 +35,11 @@ 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]).
 
 -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
@@ -49,7 +49,7 @@ This was optional in prior versions of git, but now it is the
 default.   You could 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::
@@ -61,17 +61,17 @@ default.   You could use `--no-utf8` to override this.
 
 -b::
 --binary::
-	Pass `--allow-binary-replacement` flag to `git-apply`
+	Pass `--allow-binary-replacement` flag to 'git-apply'
 	(see linkgit:git-apply[1]).
 
 --whitespace=<option>::
-	This flag is passed to the `git-apply` (see linkgit:git-apply[1])
+	This flag is passed to the 'git-apply' (see linkgit:git-apply[1])
 	program that applies
 	the patch.
 
 -C<n>::
 -p<n>::
-	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.
 
@@ -97,7 +97,7 @@ default.   You could use `--no-utf8` to override this.
 	to the screen before exiting.  This overrides the
 	standard message informing you to use `--resolved`
 	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'.
 
 DISCUSSION
 ----------

Documentation/git-apply.txt

@@ -64,7 +64,7 @@ OPTIONS
 	without using the working tree. This implies '--index'.
 
 --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 is available locally,
@@ -78,7 +78,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
@@ -102,7 +102,7 @@ the information is read from the current index instead.
 	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
@@ -113,7 +113,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
 	information you asked without actually applying the
 	patch.  Give this flag after those flags to also apply
 	the patch.
@@ -191,7 +191,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

Documentation/git-archimport.txt

@@ -29,17 +29,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
@@ -84,7 +84,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--branch, whereas new-style branch names are
 	archive,category--branch--version.  In both cases, names given
 	on the command-line will override the automatically-generated

Documentation/git-archive.txt

@@ -20,13 +20,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 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
@@ -57,7 +57,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.

Documentation/git-bisect.txt

@@ -26,7 +26,7 @@ on the subcommand:
  git bisect log
  git bisect run <cmd>...
 
-This command uses `git-rev-list --bisect` to help drive the
+This command uses 'git-rev-list --bisect' to help drive the
 binary search process to find which change introduced a bug, given an
 old "good" commit object name and a later "bad" commit object name.
 
@@ -101,7 +101,7 @@ $ git bisect visualize
 to see the currently remaining suspects in `gitk`.  `visualize` is a bit
 too long to type and `view` is provided as a synonym.
 
-If 'DISPLAY' environment variable is not set, `git-log` is used
+If 'DISPLAY' environment variable is not set, 'git-log' is used
 instead.  You can even give command line options such as `-p` and
 `--stat`.
 
@@ -215,7 +215,7 @@ tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
 work around other 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, with the "run" script, you can apply that tweak
 before compiling, run the real test, and after the test decides if the
 revision (possibly with the needed tweaks) passed the test, rewind the

Documentation/git-blame.txt

@@ -21,7 +21,7 @@ last modified the line. Optionally, start annotating from the given revision.
 Also it can limit the range of lines annotated.
 
 This report doesn't 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
@@ -49,7 +49,7 @@ include::blame-options.txt[]
 	file (see `-M`).  The first number listed is the score.
 	This is the number of alphanumeric characters detected
 	to be 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::
@@ -100,7 +100,7 @@ header elements later.
 SPECIFYING RANGES
 -----------------
 
-Unlike `git-blame` and `git-annotate` in older git, the extent
+Unlike 'git-blame' and 'git-annotate' in older git, the extent
 of annotation can be limited to both line ranges and revision
 ranges.  When you are interested in finding the origin for
 ll. 40-60 for file `foo`, you can use `-L` option like these
@@ -118,7 +118,7 @@ would limit the annotation to the body of `hello` subroutine.
 
 When you are not interested in changes older than the 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