@matheusbsbs / matheus-bagliano / commits / ba020ef5eb
Fork 0

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 <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Jonathan Nieder committed Jul 3, 2008 at 00:41 UTC ba020ef5eb5fca3d757bd580ff117adaf81ca079
117 files changed +712 -712
Documentation/config.txt
+27 -27
@@ -63,7 +63,7 @@ The values following the equals sign in variable assign are all either
63 a string, an integer, or a boolean. Boolean values may be given as yes/no,
64 0/1 or true/false. Case is not significant in boolean values, when
65 converting value to the canonical form using '--bool' type specifier;
66 -`git-config` will ensure that the output is "true" or "false".
66 +'git-config' will ensure that the output is "true" or "false".
67
68 String values may be entirely or partially enclosed in double quotes.
69 You need to enclose variable value in double quotes if you want to
@@ -356,8 +356,8 @@ core.pager::
356
357 core.whitespace::
358 A comma separated list of common whitespace problems to
359 - notice. `git-diff` will use `color.diff.whitespace` to
360 - highlight them, and `git-apply --whitespace=error` will
359 + notice. 'git-diff' will use `color.diff.whitespace` to
360 + highlight them, and 'git-apply --whitespace=error' will
361 consider them as errors:
362 +
363 * `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
396 "gitk --all --not ORIG_HEAD".
397
398 apply.whitespace::
399 - Tells `git-apply` how to handle whitespaces, in the same way
399 + Tells 'git-apply' how to handle whitespaces, in the same way
400 as the '--whitespace' option. See linkgit:git-apply[1].
401
402 branch.autosetupmerge::
403 - Tells `git-branch` and `git-checkout` to setup new branches
403 + Tells 'git-branch' and 'git-checkout' to setup new branches
404 so that linkgit:git-pull[1] will appropriately merge from the
405 starting point branch. Note that even if this option is not set,
406 this behavior can be chosen per-branch using the `--track`
@@ -411,7 +411,7 @@ branch.autosetupmerge::
411 branch. This option defaults to true.
412
413 branch.autosetuprebase::
414 - When a new branch is created with `git-branch` or `git-checkout`
414 + When a new branch is created with 'git-branch' or 'git-checkout'
415 that tracks another branch, this variable tells git to set
416 up pull to rebase instead of merge (see "branch.<name>.rebase").
417 When `never`, rebase is never automatically set to true.
@@ -426,20 +426,20 @@ branch.autosetuprebase::
426 This option defaults to never.
427
428 branch.<name>.remote::
429 - When in branch <name>, it tells `git-fetch` which remote to fetch.
430 - If this option is not given, `git-fetch` defaults to remote "origin".
429 + When in branch <name>, it tells 'git-fetch' which remote to fetch.
430 + If this option is not given, 'git-fetch' defaults to remote "origin".
431
432 branch.<name>.merge::
433 - When in branch <name>, it tells `git-fetch` the default
433 + When in branch <name>, it tells 'git-fetch' the default
434 refspec to be marked for merging in FETCH_HEAD. The value is
435 handled like the remote part of a refspec, and must match a
436 ref which is fetched from the remote given by
437 "branch.<name>.remote".
438 - The merge information is used by `git-pull` (which at first calls
439 - `git-fetch`) to lookup the default branch for merging. Without
440 - this option, `git-pull` defaults to merge the first refspec fetched.
438 + The merge information is used by 'git-pull' (which at first calls
439 + 'git-fetch') to lookup the default branch for merging. Without
440 + this option, 'git-pull' defaults to merge the first refspec fetched.
441 Specify multiple values to get an octopus merge.
442 - If you wish to setup `git-pull` so that it merges into <name> from
442 + If you wish to setup 'git-pull' so that it merges into <name> from
443 another branch in the local repository, you can point
444 branch.<name>.merge to the desired branch, and use the special setting
445 `.` (a period) for branch.<name>.remote.
@@ -513,7 +513,7 @@ color.interactive::
513 colors only when the output is to the terminal. Defaults to false.
514
515 color.interactive.<slot>::
516 - Use customized color for `git-add --interactive`
516 + Use customized color for 'git-add --interactive'
517 output. `<slot>` may be `prompt`, `header`, or `help`, for
518 three distinct types of normal output from interactive
519 programs. The values of these variables may be specified as
@@ -550,14 +550,14 @@ color.ui::
550 take precedence over this setting. Defaults to false.
551
552 diff.autorefreshindex::
553 - When using `git-diff` to compare with work tree
553 + When using 'git-diff' to compare with work tree
554 files, do not consider stat-only change as changed.
555 Instead, silently run `git update-index --refresh` to
556 update the cached stat information for paths whose
557 contents in the work tree match the contents in the
558 index. This option defaults to true. Note that this
559 - affects only `git-diff` Porcelain, and not lower level
560 - `diff` commands, such as `git-diff-files`.
559 + affects only 'git-diff' Porcelain, and not lower level
560 + `diff` commands, such as 'git-diff-files'.
561
562 diff.external::
563 If this config variable is set, diff generation is not
@@ -625,37 +625,37 @@ gc.autopacklimit::
625 default value is 50. Setting this to 0 disables it.
626
627 gc.packrefs::
628 - `git-gc` does not run `git pack-refs` in a bare repository by
628 + 'git-gc' does not run `git pack-refs` in a bare repository by
629 default so that older dumb-transport clients can still fetch
630 - from the repository. Setting this to `true` lets `git-gc`
630 + from the repository. Setting this to `true` lets 'git-gc'
631 to run `git pack-refs`. Setting this to `false` tells
632 - `git-gc` never to run `git pack-refs`. The default setting is
632 + 'git-gc' never to run `git pack-refs`. The default setting is
633 `notbare`. Enable it only when you know you do not have to
634 support such clients. The default setting will change to `true`
635 at some stage, and setting this to `false` will continue to
636 - prevent `git pack-refs` from being run from `git-gc`.
636 + prevent `git pack-refs` from being run from 'git-gc'.
637
638 gc.pruneexpire::
639 - When `git-gc` is run, it will call `prune --expire 2.weeks.ago`.
639 + When 'git-gc' is run, it will call `prune --expire 2.weeks.ago`.
640 Override the grace period with this config variable.
641
642 gc.reflogexpire::
643 - `git-reflog expire` removes reflog entries older than
643 + 'git-reflog expire' removes reflog entries older than
644 this time; defaults to 90 days.
645
646 gc.reflogexpireunreachable::
647 - `git-reflog expire` removes reflog entries older than
647 + 'git-reflog expire' removes reflog entries older than
648 this time and are not reachable from the current tip;
649 defaults to 30 days.
650
651 gc.rerereresolved::
652 Records of conflicted merge you resolved earlier are
653 - kept for this many days when `git-rerere gc` is run.
653 + kept for this many days when 'git-rerere gc' is run.
654 The default is 60 days. See linkgit:git-rerere[1].
655
656 gc.rerereunresolved::
657 Records of conflicted merge you have not resolved are
658 - kept for this many days when `git-rerere gc` is run.
658 + kept for this many days when 'git-rerere gc' is run.
659 The default is 15 days. See linkgit:git-rerere[1].
660
661 rerere.enabled::
@@ -821,7 +821,7 @@ i18n.commitEncoding::
821
822 i18n.logOutputEncoding::
823 Character encoding the commit messages are converted to when
824 - running `git-log` and friends.
824 + running 'git-log' and friends.
825
826 instaweb.browser::
827 Specify the program that will be used to browse your working
Documentation/fetch-options.txt
+4 -4
@@ -21,7 +21,7 @@
21
22 -f::
23 --force::
24 - When `git-fetch` is used with `<rbranch>:<lbranch>`
24 + When 'git-fetch' is used with `<rbranch>:<lbranch>`
25 refspec, it refuses to update the local branch
26 `<lbranch>` unless the remote branch `<rbranch>` it
27 fetches is a descendant of `<lbranch>`. This option
@@ -53,10 +53,10 @@ endif::git-pull[]
53
54 -u::
55 --update-head-ok::
56 - By default `git-fetch` refuses to update the head which
56 + By default 'git-fetch' refuses to update the head which
57 corresponds to the current branch. This flag disables the
58 - check. This is purely for the internal use for `git-pull`
59 - to communicate with `git-fetch`, and unless you are
58 + check. This is purely for the internal use for 'git-pull'
59 + to communicate with 'git-fetch', and unless you are
60 implementing your own Porcelain you are not supposed to
61 use it.
62
Documentation/git-am.txt
+7 -7
@@ -35,11 +35,11 @@ OPTIONS
35
36 -k::
37 --keep::
38 - Pass `-k` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
38 + Pass `-k` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
39
40 -u::
41 --utf8::
42 - Pass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
42 + Pass `-u` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
43 The proposed commit log message taken from the e-mail
44 is re-coded into UTF-8 encoding (configuration variable
45 `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
49 default. You could use `--no-utf8` to override this.
50
51 --no-utf8::
52 - Pass `-n` flag to `git-mailinfo` (see
52 + Pass `-n` flag to 'git-mailinfo' (see
53 linkgit:git-mailinfo[1]).
54
55 -3::
@@ -61,17 +61,17 @@ default. You could use `--no-utf8` to override this.
61
62 -b::
63 --binary::
64 - Pass `--allow-binary-replacement` flag to `git-apply`
64 + Pass `--allow-binary-replacement` flag to 'git-apply'
65 (see linkgit:git-apply[1]).
66
67 --whitespace=<option>::
68 - This flag is passed to the `git-apply` (see linkgit:git-apply[1])
68 + This flag is passed to the 'git-apply' (see linkgit:git-apply[1])
69 program that applies
70 the patch.
71
72 -C<n>::
73 -p<n>::
74 - These flags are passed to the `git-apply` (see linkgit:git-apply[1])
74 + These flags are passed to the 'git-apply' (see linkgit:git-apply[1])
75 program that applies
76 the patch.
77
@@ -97,7 +97,7 @@ default. You could use `--no-utf8` to override this.
97 to the screen before exiting. This overrides the
98 standard message informing you to use `--resolved`
99 or `--skip` to handle the failure. This is solely
100 - for internal use between `git-rebase` and `git-am`.
100 + for internal use between 'git-rebase' and 'git-am'.
101
102 DISCUSSION
103 ----------
Documentation/git-apply.txt
+5 -5
@@ -64,7 +64,7 @@ OPTIONS
64 without using the working tree. This implies '--index'.
65
66 --build-fake-ancestor <file>::
67 - Newer `git-diff` output has embedded 'index information'
67 + Newer 'git-diff' output has embedded 'index information'
68 for each blob to help identify the original version that
69 the patch applies to. When this flag is given, and if
70 the original versions of the blobs is available locally,
@@ -78,7 +78,7 @@ the information is read from the current index instead.
78 Apply the patch in reverse.
79
80 --reject::
81 - For atomicity, `git-apply` by default fails the whole patch and
81 + For atomicity, 'git-apply' by default fails the whole patch and
82 does not touch the working tree when some of the hunks
83 do not apply. This option makes it apply
84 the parts of the patch that are applicable, and leave the
@@ -102,7 +102,7 @@ the information is read from the current index instead.
102 ever ignored.
103
104 --unidiff-zero::
105 - By default, `git-apply` expects that the patch being
105 + By default, 'git-apply' expects that the patch being
106 applied is a unified diff with at least one line of context.
107 This provides good safety measures, but breaks down when
108 applying a diff generated with --unified=0. To bypass these
@@ -113,7 +113,7 @@ discouraged.
113
114 --apply::
115 If you use any of the options marked "Turns off
116 - 'apply'" above, `git-apply` reads and outputs the
116 + 'apply'" above, 'git-apply' reads and outputs the
117 information you asked without actually applying the
118 patch. Give this flag after those flags to also apply
119 the patch.
@@ -191,7 +191,7 @@ apply.whitespace::
191
192 Submodules
193 ----------
194 -If the patch contains any changes to submodules then `git-apply`
194 +If the patch contains any changes to submodules then 'git-apply'
195 treats these changes as follows.
196
197 If --index is specified (explicitly or implicitly), then the submodule
Documentation/git-archimport.txt
+6 -6
@@ -29,17 +29,17 @@ branches that have different roots, it will refuse to run. In that case,
29 edit your <archive/branch> parameters to define clearly the scope of the
30 import.
31
32 -`git-archimport` uses `tla` extensively in the background to access the
32 +'git-archimport' uses `tla` extensively in the background to access the
33 Arch repository.
34 Make sure you have a recent version of `tla` available in the path. `tla` must
35 -know about the repositories you pass to `git-archimport`.
35 +know about the repositories you pass to 'git-archimport'.
36
37 -For the initial import, `git-archimport` expects to find itself in an empty
37 +For the initial import, 'git-archimport' expects to find itself in an empty
38 directory. To follow the development of a project that uses Arch, rerun
39 -`git-archimport` with the same parameters as the initial import to perform
39 +'git-archimport' with the same parameters as the initial import to perform
40 incremental imports.
41
42 -While `git-archimport` will try to create sensible branch names for the
42 +While 'git-archimport' will try to create sensible branch names for the
43 archives that it imports, it is also possible to specify git branch names
44 manually. To do so, write a git branch name after each <archive/branch>
45 parameter, separated by a colon. This way, you can shorten the Arch
@@ -84,7 +84,7 @@ OPTIONS
84
85 -o::
86 Use this for compatibility with old-style branch names used by
87 - earlier versions of `git-archimport`. Old-style branch names
87 + earlier versions of 'git-archimport'. Old-style branch names
88 were category--branch, whereas new-style branch names are
89 archive,category--branch--version. In both cases, names given
90 on the command-line will override the automatically-generated
Documentation/git-archive.txt
+3 -3
@@ -20,13 +20,13 @@ structure for the named tree, and writes it out to the standard
20 output. If <prefix> is specified it is
21 prepended to the filenames in the archive.
22
23 -`git-archive` behaves differently when given a tree ID versus when
23 +'git-archive' behaves differently when given a tree ID versus when
24 given a commit ID or tag ID. In the first case the current time is
25 used as modification time of each file in the archive. In the latter
26 case the commit time as recorded in the referenced commit object is
27 used instead. Additionally the commit ID is stored in a global
28 extended pax header if the tar format is used; it can be extracted
29 -using `git-get-tar-commit-id`. In ZIP files it is stored as a file
29 +using 'git-get-tar-commit-id'. In ZIP files it is stored as a file
30 comment.
31
32 OPTIONS
@@ -57,7 +57,7 @@ OPTIONS
57
58 --exec=<git-upload-archive>::
59 Used with --remote to specify the path to the
60 - `git-upload-archive` on the remote side.
60 + 'git-upload-archive' on the remote side.
61
62 <tree-ish>::
63 The tree or commit to produce an archive for.
Documentation/git-bisect.txt
+3 -3
@@ -26,7 +26,7 @@ on the subcommand:
26 git bisect log
27 git bisect run <cmd>...
28
29 -This command uses `git-rev-list --bisect` to help drive the
29 +This command uses 'git-rev-list --bisect' to help drive the
30 binary search process to find which change introduced a bug, given an
31 old "good" commit object name and a later "bad" commit object name.
32
@@ -101,7 +101,7 @@ $ git bisect visualize
101 to see the currently remaining suspects in `gitk`. `visualize` is a bit
102 too long to type and `view` is provided as a synonym.
103
104 -If 'DISPLAY' environment variable is not set, `git-log` is used
104 +If 'DISPLAY' environment variable is not set, 'git-log' is used
105 instead. You can even give command line options such as `-p` and
106 `--stat`.
107
@@ -215,7 +215,7 @@ tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
215 work around other problem this bisection is not interested in")
216 applied to the revision being tested.
217
218 -To cope with such a situation, after the inner `git-bisect` finds the
218 +To cope with such a situation, after the inner 'git-bisect' finds the
219 next revision to test, with the "run" script, you can apply that tweak
220 before compiling, run the real test, and after the test decides if the
221 revision (possibly with the needed tweaks) passed the test, rewind the
Documentation/git-blame.txt
+4 -4
@@ -21,7 +21,7 @@ last modified the line. Optionally, start annotating from the given revision.
21 Also it can limit the range of lines annotated.
22
23 This report doesn't tell you anything about lines which have been deleted or
24 -replaced; you need to use a tool such as `git-diff` or the "pickaxe"
24 +replaced; you need to use a tool such as 'git-diff' or the "pickaxe"
25 interface briefly mentioned in the following paragraph.
26
27 Apart from supporting file annotation, git also supports searching the
@@ -49,7 +49,7 @@ include::blame-options.txt[]
49 file (see `-M`). The first number listed is the score.
50 This is the number of alphanumeric characters detected
51 to be moved between or within files. This must be above
52 - a certain threshold for `git-blame` to consider those lines
52 + a certain threshold for 'git-blame' to consider those lines
53 of code to have been moved.
54
55 -f::
@@ -100,7 +100,7 @@ header elements later.
100 SPECIFYING RANGES
101 -----------------
102
103 -Unlike `git-blame` and `git-annotate` in older git, the extent
103 +Unlike 'git-blame' and 'git-annotate' in older git, the extent
104 of annotation can be limited to both line ranges and revision
105 ranges. When you are interested in finding the origin for
106 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.
118
119 When you are not interested in changes older than the version
120 v2.6.18, or changes older than 3 weeks, you can use revision
121 -range specifiers similar to `git-rev-list`:
121 +range specifiers similar to 'git-rev-list':
122
123 git blame v2.6.18.. -- foo
124 git blame --since=3.weeks -- foo
Documentation/git-branch.txt
+4 -4
@@ -37,7 +37,7 @@ working tree to it; use "git checkout <newbranch>" to switch to the
37 new branch.
38
39 When a local branch is started off a remote branch, git sets up the
40 -branch so that `git-pull` will appropriately merge from
40 +branch so that 'git-pull' will appropriately merge from
41 the remote branch. This behavior may be changed via the global
42 `branch.autosetupmerge` configuration flag. That setting can be
43 overridden by using the `--track` and `--no-track` options.
@@ -54,7 +54,7 @@ has a reflog then the reflog will also be deleted.
54
55 Use -r together with -d to delete remote-tracking branches. Note, that it
56 only makes sense to delete remote-tracking branches if they no longer exist
57 -in remote repository or if `git-fetch` was configured not to fetch
57 +in remote repository or if 'git-fetch' was configured not to fetch
58 them again. See also 'prune' subcommand of linkgit:git-remote[1] for way to
59 clean up all obsolete remote-tracking branches.
60
@@ -107,14 +107,14 @@ OPTIONS
107 Display the full sha1s in output listing rather than abbreviating them.
108
109 --track::
110 - When creating a new branch, set up configuration so that `git-pull`
110 + When creating a new branch, set up configuration so that 'git-pull'
111 will automatically retrieve data from the start point, which must be
112 a branch. Use this if you always pull from the same upstream branch
113 into the new branch, and if you don't want to use "git pull
114 <repository> <refspec>" explicitly. This behavior is the default
115 when the start point is a remote branch. Set the
116 branch.autosetupmerge configuration variable to `false` if you want
117 - `git-checkout` and `git-branch` to always behave as if '--no-track' were
117 + 'git-checkout' and 'git-branch' to always behave as if '--no-track' were
118 given. Set it to `always` if you want this behavior when the
119 start-point is either a local or remote branch.
120
Documentation/git-bundle.txt
+13 -13
@@ -21,9 +21,9 @@ Some workflows require that one or more branches of development on one
21 machine be replicated on another machine, but the two machines cannot
22 be directly connected so the interactive git protocols (git, ssh,
23 rsync, http) cannot be used. This command provides support for
24 -`git-fetch` and `git-pull` to operate by packaging objects and references
24 +'git-fetch' and 'git-pull' to operate by packaging objects and references
25 in an archive at the originating machine, then importing those into
26 -another repository using `git-fetch` and `git-pull`
26 +another repository using 'git-fetch' and 'git-pull'
27 after moving the archive by some means (i.e., by sneakernet). As no
28 direct connection between repositories exists, the user must specify a
29 basis for the bundle that is held by the destination repository: the
@@ -35,14 +35,14 @@ OPTIONS
35
36 create <file>::
37 Used to create a bundle named 'file'. This requires the
38 - `git-rev-list` arguments to define the bundle contents.
38 + 'git-rev-list' arguments to define the bundle contents.
39
40 verify <file>::
41 Used to check that a bundle file is valid and will apply
42 cleanly to the current repository. This includes checks on the
43 bundle format itself as well as checking that the prerequisite
44 commits exist and are fully linked in the current repository.
45 - `git-bundle` prints a list of missing commits, if any, and exits
45 + 'git-bundle' prints a list of missing commits, if any, and exits
46 with non-zero status.
47
48 list-heads <file>::
@@ -51,15 +51,15 @@ list-heads <file>::
51 printed out.
52
53 unbundle <file>::
54 - Passes the objects in the bundle to `git-index-pack`
54 + Passes the objects in the bundle to 'git-index-pack'
55 for storage in the repository, then prints the names of all
56 defined references. If a reflist is given, only references
57 matching those in the given list are printed. This command is
58 - really plumbing, intended to be called only by `git-fetch`.
58 + really plumbing, intended to be called only by 'git-fetch'.
59
60 [git-rev-list-args...]::
61 - A list of arguments, acceptable to `git-rev-parse` and
62 - `git-rev-list`, that specify the specific objects and references
61 + A list of arguments, acceptable to 'git-rev-parse' and
62 + 'git-rev-list', that specify the specific objects and references
63 to transport. For example, "master~10..master" causes the
64 current master reference to be packaged along with all objects
65 added since its 10th ancestor commit. There is no explicit
@@ -69,16 +69,16 @@ unbundle <file>::
69
70 [refname...]::
71 A list of references used to limit the references reported as
72 - available. This is principally of use to `git-fetch`, which
72 + available. This is principally of use to 'git-fetch', which
73 expects to receive only those references asked for and not
74 - necessarily everything in the pack (in this case, `git-bundle` is
75 - acting like `git-fetch-pack`).
74 + necessarily everything in the pack (in this case, 'git-bundle' is
75 + acting like 'git-fetch-pack').
76
77 SPECIFYING REFERENCES
78 ---------------------
79
80 -`git-bundle` will only package references that are shown by
81 -`git-show-ref`: this includes heads, tags, and remote heads. References
80 +'git-bundle' will only package references that are shown by
81 +'git-show-ref': this includes heads, tags, and remote heads. References
82 such as master~1 cannot be packaged, but are perfectly suitable for
83 defining the basis. More than one reference may be packaged, and more
84 than one basis can be specified. The objects packaged are those not
Documentation/git-check-ref-format.txt
+1 -1
@@ -47,7 +47,7 @@ refname expressions (see linkgit:git-rev-parse[1]). Namely:
47 . colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
48 value and store it in dstref" in fetch and push operations.
49 It may also be used to select a specific object such as with
50 - `git-cat-file`: "git cat-file blob v1.3.3:refs.c".
50 + 'git-cat-file': "git cat-file blob v1.3.3:refs.c".
51
52
53 GIT
Documentation/git-checkout-index.txt
+4 -4
@@ -88,7 +88,7 @@ $ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
88 which will force all existing `*.h` files to be replaced with their
89 cached copies. If an empty command line implied "all", then this would
90 force-refresh everything in the index, which was not the point. But
91 -since `git-checkout-index` accepts --stdin it would be faster to use:
91 +since 'git-checkout-index' accepts --stdin it would be faster to use:
92
93 ----------------
94 $ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
@@ -102,7 +102,7 @@ Using `--` is probably a good policy in scripts.
102 Using --temp or --stage=all
103 ---------------------------
104 When `--temp` is used (or implied by `--stage=all`)
105 -`git-checkout-index` will create a temporary file for each index
105 +'git-checkout-index' will create a temporary file for each index
106 entry being checked out. The index will not be updated with stat
107 information. These options can be useful if the caller needs all
108 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::
147 $ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
148 ----------------
149
150 -Using `git-checkout-index` to "export an entire tree"::
150 +Using 'git-checkout-index' to "export an entire tree"::
151 The prefix ability basically makes it trivial to use
152 - `git-checkout-index` as an "export as tree" function.
152 + 'git-checkout-index' as an "export as tree" function.
153 Just read the desired tree into the index, and do:
154 +
155 ----------------
Documentation/git-checkout.txt
+2 -2
@@ -49,14 +49,14 @@ OPTIONS
49
50 -t::
51 --track::
52 - When creating a new branch, set up configuration so that `git-pull`
52 + When creating a new branch, set up configuration so that 'git-pull'
53 will automatically retrieve data from the start point, which must be
54 a branch. Use this if you always pull from the same upstream branch
55 into the new branch, and if you don't want to use "git pull
56 <repository> <refspec>" explicitly. This behavior is the default
57 when the start point is a remote branch. Set the
58 branch.autosetupmerge configuration variable to `false` if you want
59 - `git-checkout` and `git-branch` to always behave as if '--no-track' were
59 + 'git-checkout' and 'git-branch' to always behave as if '--no-track' were
60 given. Set it to `always` if you want this behavior when the
61 start-point is either a local or remote branch.
62
Documentation/git-cherry-pick.txt
+1 -1
@@ -24,7 +24,7 @@ OPTIONS
24
25 -e::
26 --edit::
27 - With this option, `git-cherry-pick` will let you edit the commit
27 + With this option, 'git-cherry-pick' will let you edit the commit
28 message prior to committing.
29
30 -x::
Documentation/git-cherry.txt
+3 -3
@@ -14,7 +14,7 @@ DESCRIPTION
14 The changeset (or "diff") of each commit between the fork-point and <head>
15 is compared against each commit between the fork-point and <upstream>.
16 The commits are compared with their 'patch id', obtained from
17 -the `git-patch-id` program.
17 +the 'git-patch-id' program.
18
19 Every commit that doesn't exist in the <upstream> branch
20 has its id (sha1) reported, prefixed by a symbol. The ones that have
@@ -37,8 +37,8 @@ to and including <limit> are not reported:
37 \__*__*__<limit>__-__+__> <head>
38
39
40 -Because `git-cherry` compares the changeset rather than the commit id
41 -(sha1), you can use `git-cherry` to find out if a commit you made locally
40 +Because 'git-cherry' compares the changeset rather than the commit id
41 +(sha1), you can use 'git-cherry' to find out if a commit you made locally
42 has been applied <upstream> under a different commit id. For example,
43 this will happen if you're feeding patches <upstream> via email rather
44 than pushing or pulling commits directly.
Documentation/git-citool.txt
+2 -2
@@ -14,9 +14,9 @@ DESCRIPTION
14 A Tcl/Tk based graphical interface to review modified files, stage
15 them into the index, enter a commit message and record the new
16 commit onto the current branch. This interface is an alternative
17 -to the less interactive `git-commit` program.
17 +to the less interactive 'git-commit' program.
18
19 -`git-citool` is actually a standard alias for `git gui citool`.
19 +'git-citool' is actually a standard alias for `git gui citool`.
20 See linkgit:git-gui[1] for more details.
21
22 Author
Documentation/git-clean.txt
+2 -2
@@ -27,7 +27,7 @@ OPTIONS
27
28 -f::
29 If the git configuration specifies clean.requireForce as true,
30 - `git-clean` will refuse to run unless given -f or -n.
30 + 'git-clean' will refuse to run unless given -f or -n.
31
32 -n::
33 --dry-run::
@@ -41,7 +41,7 @@ OPTIONS
41 -x::
42 Don't use the ignore rules. This allows removing all untracked
43 files, including build products. This can be used (possibly in
44 - conjunction with `git-reset`) to create a pristine
44 + conjunction with 'git-reset') to create a pristine
45 working directory to test a clean build.
46
47 -X::
Documentation/git-clone.txt
+3 -3
@@ -68,7 +68,7 @@ it unless you understand what it does. If you clone your
68 repository using this option and then delete branches (or use any
69 other git command that makes any existing commit unreferenced) in the
70 source repository, some objects may become unreferenced (or dangling).
71 -These objects may be removed by normal git operations (such as `git-commit`)
71 +These objects may be removed by normal git operations (such as 'git-commit')
72 which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
73 If these objects are removed and were referenced by the cloned repository,
74 then the cloned repository will become corrupt.
@@ -88,7 +88,7 @@ then the cloned repository will become corrupt.
88 --quiet::
89 -q::
90 Operate quietly. This flag is passed to "rsync" and
91 - `git-fetch-pack` commands when given.
91 + 'git-fetch-pack' commands when given.
92
93 --no-checkout::
94 -n::
@@ -114,7 +114,7 @@ then the cloned repository will become corrupt.
114 --upload-pack <upload-pack>::
115 -u <upload-pack>::
116 When given, and the repository to clone from is handled
117 - by `git-fetch-pack`, `--exec=<upload-pack>` is passed to
117 + by 'git-fetch-pack', `--exec=<upload-pack>` is passed to
118 the command to specify non-default path for the command
119 run on the other end.
120
Documentation/git-commit-tree.txt
+1 -1
@@ -70,7 +70,7 @@ is taken from the configuration items user.name and user.email, or, if not
70 present, system user name and fully qualified hostname.
71
72 A commit comment is read from stdin. If a changelog
73 -entry is not provided via "<" redirection, `git-commit-tree` will just wait
73 +entry is not provided via "<" redirection, 'git-commit-tree' will just wait
74 for one to be entered and terminated with ^D.
75
76
Documentation/git-commit.txt
+10 -10
@@ -20,11 +20,11 @@ with a log message from the user describing the changes.
20
21 The content to be added can be specified in several ways:
22
23 -1. by using `git-add` to incrementally "add" changes to the
23 +1. by using 'git-add' to incrementally "add" changes to the
24 index before using the 'commit' command (Note: even modified
25 files must be "added");
26
27 -2. by using `git-rm` to remove files from the working tree
27 +2. by using 'git-rm' to remove files from the working tree
28 and the index, again before using the 'commit' command;
29
30 3. by listing files as arguments to the 'commit' command, in which
@@ -39,15 +39,15 @@ The content to be added can be specified in several ways:
39
40 5. by using the --interactive switch with the 'commit' command to decide one
41 by one which files should be part of the commit, before finalizing the
42 - operation. Currently, this is done by invoking `git-add --interactive`.
42 + operation. Currently, this is done by invoking 'git-add --interactive'.
43
44 -The `git-status` command can be used to obtain a
44 +The 'git-status' command can be used to obtain a
45 summary of what is included by any of the above for the next
46 commit by giving the same set of parameters you would give to
47 this command.
48
49 If you make a commit and then find a mistake immediately after
50 -that, you can recover from it with `git-reset`.
50 +that, you can recover from it with 'git-reset'.
51
52
53 OPTIONS
@@ -205,10 +205,10 @@ EXAMPLES
205 --------
206 When recording your own work, the contents of modified files in
207 your working tree are temporarily stored to a staging area
208 -called the "index" with `git-add`. A file can be
208 +called the "index" with 'git-add'. A file can be
209 reverted back, only in the index but not in the working tree,
210 to that of the last commit with `git reset HEAD -- <file>`,
211 -which effectively reverts `git-add` and prevents the changes to
211 +which effectively reverts 'git-add' and prevents the changes to
212 this file from participating in the next commit. After building
213 the state to be committed incrementally with these commands,
214 `git commit` (without any pathname parameter) is used to record what
@@ -264,13 +264,13 @@ $ git commit
264 this second commit would record the changes to `hello.c` and
265 `hello.h` as expected.
266
267 -After a merge (initiated by `git-merge` or `git-pull`) stops
267 +After a merge (initiated by 'git-merge' or 'git-pull') stops
268 because of conflicts, cleanly merged
269 paths are already staged to be committed for you, and paths that
270 conflicted are left in unmerged state. You would have to first
271 -check which paths are conflicting with `git-status`
271 +check which paths are conflicting with 'git-status'
272 and after fixing them manually in your working tree, you would
273 -stage the result as usual with `git-add`:
273 +stage the result as usual with 'git-add':
274
275 ------------
276 $ git status | grep unmerged
Documentation/git-config.txt
+6 -6
@@ -37,7 +37,7 @@ you want to handle the lines that do *not* match the regex, just
37 prepend a single exclamation mark in front (see also <<EXAMPLES>>).
38
39 The type specifier can be either '--int' or '--bool', which will make
40 -`git-config` ensure that the variable(s) are of the given type and
40 +'git-config' ensure that the variable(s) are of the given type and
41 convert the value to the canonical form (simple decimal number for int,
42 a "true" or "false" string for bool). If no type specifier is passed,
43 no checks or transformations are performed on the value.
@@ -122,10 +122,10 @@ See also <<FILES>>.
122 List all variables set in config file.
123
124 --bool::
125 - `git-config` will ensure that the output is "true" or "false"
125 + 'git-config' will ensure that the output is "true" or "false"
126
127 --int::
128 - `git-config` will ensure that the output is a simple
128 + 'git-config' will ensure that the output is a simple
129 decimal number. An optional value suffix of 'k', 'm', or 'g'
130 in the config file will cause the value to be multiplied
131 by 1024, 1048576, or 1073741824 prior to output.
@@ -162,7 +162,7 @@ FILES
162 -----
163
164 If not set explicitly with '--file', there are three files where
165 -`git-config` will search for configuration options:
165 +'git-config' will search for configuration options:
166
167 $GIT_DIR/config::
168 Repository specific configuration file. (The filename is
@@ -179,12 +179,12 @@ $(prefix)/etc/gitconfig::
179 If no further options are given, all reading options will read all of these
180 files that are available. If the global or the system-wide configuration
181 file are not available they will be ignored. If the repository configuration
182 -file is not available or readable, `git-config` will exit with a non-zero
182 +file is not available or readable, 'git-config' will exit with a non-zero
183 error code. However, in neither case will an error message be issued.
184
185 All writing options will per default write to the repository specific
186 configuration file. Note that this also affects options like '--replace-all'
187 -and '--unset'. *`git-config` will only ever change one file at a time*.
187 +and '--unset'. *'git-config' will only ever change one file at a time*.
188
189 You can override these rules either by command line options or by environment
190 variables. The '--global' and the '--system' options will limit the file used
Documentation/git-cvsexportcommit.txt
+1 -1
@@ -27,7 +27,7 @@ by default.
27
28 Supports file additions, removals, and commits that affect binary files.
29
30 -If the commit is a merge commit, you must tell `git-cvsexportcommit` what
30 +If the commit is a merge commit, you must tell 'git-cvsexportcommit' what
31 parent the changeset should be done against.
32
33 OPTIONS
Documentation/git-cvsimport.txt
+9 -9
@@ -25,9 +25,9 @@ Splitting the CVS log into patch sets is done by 'cvsps'.
25 At least version 2.1 is required.
26
27 You should *never* do any work of your own on the branches that are
28 -created by `git-cvsimport`. By default initial import will create and populate a
28 +created by 'git-cvsimport'. By default initial import will create and populate a
29 "master" branch from the CVS repository's main branch which you're free
30 -to work with; after that, you need to `git-merge` incremental imports, or
30 +to work with; after that, you need to 'git-merge' incremental imports, or
31 any CVS branches, yourself. It is advisable to specify a named remote via
32 -r to separate and protect the incoming branches.
33
@@ -40,13 +40,13 @@ OPTIONS
40 -d <CVSROOT>::
41 The root of the CVS archive. May be local (a simple path) or remote;
42 currently, only the :local:, :ext: and :pserver: access methods
43 - are supported. If not given, `git-cvsimport` will try to read it
43 + are supported. If not given, 'git-cvsimport' will try to read it
44 from `CVS/Root`. If no such file exists, it checks for the
45 `CVSROOT` environment variable.
46
47 <CVS_module>::
48 The CVS module you want to import. Relative to <CVSROOT>.
49 - If not given, `git-cvsimport` tries to read it from
49 + If not given, 'git-cvsimport' tries to read it from
50 `CVS/Repository`.
51
52 -C <target-dir>::
@@ -56,14 +56,14 @@ OPTIONS
56 -r <remote>::
57 The git remote to import this CVS repository into.
58 Moves all CVS branches into remotes/<remote>/<branch>
59 - akin to the `git-clone` "--use-separate-remote" option.
59 + akin to the 'git-clone' "--use-separate-remote" option.
60
61 -o <branch-for-HEAD>::
62 When no remote is specified (via -r) the 'HEAD' branch
63 from CVS is imported to the 'origin' branch within the git
64 repository, as 'HEAD' already has a special meaning for git.
65 When a remote is specified the 'HEAD' branch is named
66 - remotes/<remote>/master mirroring `git-clone` behaviour.
66 + remotes/<remote>/master mirroring 'git-clone' behaviour.
67 Use this option if you want to import into a different
68 branch.
69 +
@@ -136,17 +136,17 @@ This option can be used several times to provide several detection regexes.
136
137 ---------
138 +
139 -`git-cvsimport` will make it appear as those authors had
139 +'git-cvsimport' will make it appear as those authors had
140 their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
141 all along.
142 +
143 For convenience, this data is saved to `$GIT_DIR/cvs-authors`
144 each time the '-A' option is provided and read from that same
145 -file each time `git-cvsimport` is run.
145 +file each time 'git-cvsimport' is run.
146 +
147 It is not recommended to use this feature if you intend to
148 export changes back to CVS again later with
149 -`git-cvsexportcommit`.
149 +'git-cvsexportcommit'.
150
151 -h::
152 Print a short usage message and exit.
Documentation/git-cvsserver.txt
+19 -19
@@ -77,7 +77,7 @@ over pserver for anonymous CVS access.
77
78 CVS clients cannot tag, branch or perform GIT merges.
79
80 -`git-cvsserver` maps GIT branches to CVS modules. This is very different
80 +'git-cvsserver' maps GIT branches to CVS modules. This is very different
81 from what most CVS users would expect since in CVS modules usually represent
82 one or more directories.
83
@@ -103,7 +103,7 @@ looks like
103 ------
104 No special setup is needed for SSH access, other than having GIT tools
105 in the PATH. If you have clients that do not accept the CVS_SERVER
106 -environment variable, you can rename `git-cvsserver` to `cvs`.
106 +environment variable, you can rename 'git-cvsserver' to `cvs`.
107
108 Note: Newer CVS versions (>= 1.12.11) also support specifying
109 CVS_SERVER directly in CVSROOT like
@@ -113,9 +113,9 @@ cvs -d ":ext;CVS_SERVER=git-cvsserver:user@server/path/repo.git" co <HEAD_name>
113 ------
114 This has the advantage that it will be saved in your 'CVS/Root' files and
115 you don't need to worry about always setting the correct environment
116 -variable. SSH users restricted to `git-shell` don't need to override the default
117 -with CVS_SERVER (and shouldn't) as `git-shell` understands `cvs` to mean
118 -`git-cvsserver` and pretends that the other end runs the real `cvs` better.
116 +variable. SSH users restricted to 'git-shell' don't need to override the default
117 +with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean
118 +'git-cvsserver' and pretends that the other end runs the real `cvs` better.
119 --
120 2. For each repo that you want accessible from CVS you need to edit config in
121 the repo and add the following section.
@@ -128,7 +128,7 @@ with CVS_SERVER (and shouldn't) as `git-shell` understands `cvs` to mean
128 logfile=/path/to/logfile
129
130 ------
131 -Note: you need to ensure each user that is going to invoke `git-cvsserver` has
131 +Note: you need to ensure each user that is going to invoke 'git-cvsserver' has
132 write access to the log file and to the database (see
133 <<dbbackend,Database Backend>>. If you want to offer write access over
134 SSH, the users of course also need write access to the git repository itself.
@@ -150,7 +150,7 @@ allowing access over SSH.
150 automatically saving it in your 'CVS/Root' files, then you need to set them
151 explicitly in your environment. CVSROOT should be set as per normal, but the
152 directory should point at the appropriate git repo. As above, for SSH clients
153 - _not_ restricted to `git-shell`, CVS_SERVER should be set to `git-cvsserver`.
153 + _not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'.
154 +
155 --
156 ------
@@ -178,27 +178,27 @@ allowing access over SSH.
178 Database Backend
179 ----------------
180
181 -`git-cvsserver` uses one database per git head (i.e. CVS module) to
181 +'git-cvsserver' uses one database per git head (i.e. CVS module) to
182 store information about the repository for faster access. The
183 database doesn't contain any persistent data and can be completely
184 regenerated from the git repository at any time. The database
185 needs to be updated (i.e. written to) after every commit.
186
187 If the commit is done directly by using `git` (as opposed to
188 -using `git-cvsserver`) the update will need to happen on the
189 -next repository access by `git-cvsserver`, independent of
188 +using 'git-cvsserver') the update will need to happen on the
189 +next repository access by 'git-cvsserver', independent of
190 access method and requested operation.
191
192 That means that even if you offer only read access (e.g. by using
193 -the pserver method), `git-cvsserver` should have write access to
193 +the pserver method), 'git-cvsserver' should have write access to
194 the database to work reliably (otherwise you need to make sure
195 -that the database is up-to-date any time `git-cvsserver` is executed).
195 +that the database is up-to-date any time 'git-cvsserver' is executed).
196
197 By default it uses SQLite databases in the git directory, named
198 `gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates
199 temporary files in the same directory as the database file on
200 write so it might not be enough to grant the users using
201 -`git-cvsserver` write access to the database file without granting
201 +'git-cvsserver' write access to the database file without granting
202 them write access to the directory, too.
203
204 You can configure the database backend with the following
@@ -207,7 +207,7 @@ configuration variables:
207 Configuring database backend
208 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
209
210 -`git-cvsserver` uses the Perl DBI module. Please also read
210 +'git-cvsserver' uses the Perl DBI module. Please also read
211 its documentation if changing these variables, especially
212 about `DBI->connect()`.
213
@@ -259,7 +259,7 @@ In `dbdriver` and `dbuser` you can use the following variables:
259 %a::
260 access method (one of "ext" or "pserver")
261 %u::
262 - Name of the user running `git-cvsserver`.
262 + Name of the user running 'git-cvsserver'.
263 If no name can be determined, the
264 numeric uid is used.
265
@@ -280,13 +280,13 @@ To get a checkout with the Eclipse CVS client:
280 Protocol notes: If you are using anonymous access via pserver, just select that.
281 Those using SSH access should choose the 'ext' protocol, and configure 'ext'
282 access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
283 -`git-cvsserver`. Note that password support is not good when using 'ext',
283 +'git-cvsserver'. Note that password support is not good when using 'ext',
284 you will definitely want to have SSH keys setup.
285
286 Alternatively, you can just use the non-standard extssh protocol that Eclipse
287 offer. In that case CVS_SERVER is ignored, and you will have to replace
288 -the cvs utility on the server with `git-cvsserver` or manipulate your `.bashrc`
289 -so that calling 'cvs' effectively calls `git-cvsserver`.
288 +the cvs utility on the server with 'git-cvsserver' or manipulate your `.bashrc`
289 +so that calling 'cvs' effectively calls 'git-cvsserver'.
290
291 Clients known to work
292 ---------------------
@@ -334,7 +334,7 @@ and `gitcvs.allbinary` to "guess".
334
335 Dependencies
336 ------------
337 -`git-cvsserver` depends on DBD::SQLite.
337 +'git-cvsserver' depends on DBD::SQLite.
338
339 Copyright and Authors
340 ---------------------
Documentation/git-daemon.txt
+20 -20
@@ -27,36 +27,36 @@ that service if it is enabled.
27 It verifies that the directory has the magic file "git-daemon-export-ok", and
28 it will refuse to export any git directory that hasn't explicitly been marked
29 for export this way (unless the '--export-all' parameter is specified). If you
30 -pass some directory paths as `git-daemon` arguments, you can further restrict
30 +pass some directory paths as 'git-daemon' arguments, you can further restrict
31 the offers to a whitelist comprising of those.
32
33 By default, only `upload-pack` service is enabled, which serves
34 -`git-fetch-pack` and `git-ls-remote` clients, which are invoked
35 -from `git-fetch`, `git-pull`, and `git-clone`.
34 +'git-fetch-pack' and 'git-ls-remote' clients, which are invoked
35 +from 'git-fetch', 'git-pull', and 'git-clone'.
36
37 This is ideally suited for read-only updates, i.e., pulling from
38 git repositories.
39
40 -An `upload-archive` also exists to serve `git-archive`.
40 +An `upload-archive` also exists to serve 'git-archive'.
41
42 OPTIONS
43 -------
44 --strict-paths::
45 Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
46 "/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
47 - `git-daemon` will refuse to start when this option is enabled and no
47 + 'git-daemon' will refuse to start when this option is enabled and no
48 whitelist is specified.
49
50 --base-path::
51 Remap all the path requests as relative to the given path.
52 - This is sort of "GIT root" - if you run `git-daemon` with
52 + This is sort of "GIT root" - if you run 'git-daemon' with
53 '--base-path=/srv/git' on example.com, then if you later try to pull
54 - 'git://example.com/hello.git', `git-daemon` will interpret the path
54 + 'git://example.com/hello.git', 'git-daemon' will interpret the path
55 as '/srv/git/hello.git'.
56
57 --base-path-relaxed::
58 If --base-path is enabled and repo lookup fails, with this option
59 - `git-daemon` will attempt to lookup without prefixing the base path.
59 + 'git-daemon' will attempt to lookup without prefixing the base path.
60 This is useful for switching to --base-path usage, while still
61 allowing the old paths.
62
@@ -138,7 +138,7 @@ OPTIONS
138 +
139 Giving these options is an error when used with `--inetd`; use
140 the facility of inet daemon to achieve the same before spawning
141 -`git-daemon` if needed.
141 +'git-daemon' if needed.
142
143 --enable=service::
144 --disable=service::
@@ -164,24 +164,24 @@ SERVICES
164
165 These services can be globally enabled/disabled using the
166 command line options of this command. If a finer-grained
167 -control is desired (e.g. to allow `git-archive` to be run
167 +control is desired (e.g. to allow 'git-archive' to be run
168 against only in a few selected repositories the daemon serves),
169 the per-repository configuration file can be used to enable or
170 disable them.
171
172 upload-pack::
173 - This serves `git-fetch-pack` and `git-ls-remote`
173 + This serves 'git-fetch-pack' and 'git-ls-remote'
174 clients. It is enabled by default, but a repository can
175 disable it by setting `daemon.uploadpack` configuration
176 item to `false`.
177
178 upload-archive::
179 - This serves `git-archive --remote`. It is disabled by
179 + This serves 'git-archive --remote'. It is disabled by
180 default, but a repository can enable it by setting
181 `daemon.uploadarch` configuration item to `true`.
182
183 receive-pack::
184 - This serves `git-send-pack` clients, allowing anonymous
184 + This serves 'git-send-pack' clients, allowing anonymous
185 push. It is disabled by default, as there is _no_
186 authentication in the protocol (in other words, anybody
187 can push anything into the repository, including removal
@@ -199,8 +199,8 @@ $ grep 9418 /etc/services
199 git 9418/tcp # Git Version Control System
200 ------------
201
202 -`git-daemon` as inetd server::
203 - To set up `git-daemon` as an inetd service that handles any
202 +'git-daemon' as inetd server::
203 + To set up 'git-daemon' as an inetd service that handles any
204 repository under the whitelisted set of directories, /pub/foo
205 and /pub/bar, place an entry like the following into
206 /etc/inetd all on one line:
@@ -212,8 +212,8 @@ git 9418/tcp # Git Version Control System
212 ------------------------------------------------
213
214
215 -`git-daemon` as inetd server for virtual hosts::
216 - To set up `git-daemon` as an inetd service that handles
215 +'git-daemon' as inetd server for virtual hosts::
216 + To set up 'git-daemon' as an inetd service that handles
217 repositories for different virtual hosts, `www.example.com`
218 and `www.example.org`, place an entry like the following into
219 `/etc/inetd` all on one line:
@@ -235,8 +235,8 @@ clients, a symlink from `/software` into the appropriate
235 default repository could be made as well.
236
237
238 -`git-daemon` as regular daemon for virtual hosts::
239 - To set up `git-daemon` as a regular, non-inetd service that
238 +'git-daemon' as regular daemon for virtual hosts::
239 + To set up 'git-daemon' as a regular, non-inetd service that
240 handles repositories for multiple virtual hosts based on
241 their IP addresses, start the daemon like this:
242 +
@@ -253,7 +253,7 @@ Repositories can still be accessed by hostname though, assuming
253 they correspond to these IP addresses.
254
255 selectively enable/disable services per repository::
256 - To enable `git-archive --remote` and disable `git-fetch` against
256 + To enable 'git-archive --remote' and disable 'git-fetch' against
257 a repository, have the following in the configuration file in the
258 repository (that is the file 'config' next to 'HEAD', 'refs' and
259 'objects').
Documentation/git-describe.txt
+3 -3
@@ -92,7 +92,7 @@ of commits which would be displayed by "git log v1.0.4..parent".
92 The hash suffix is "-g" + 7-char abbreviation for the tip commit
93 of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
94
95 -Doing a `git-describe` on a tag-name will just show the tag name:
95 +Doing a 'git-describe' on a tag-name will just show the tag name:
96
97 [torvalds@g5 git]$ git describe v1.0.4
98 v1.0.4
@@ -115,13 +115,13 @@ closest tagname without any suffix:
115 SEARCH STRATEGY
116 ---------------
117
118 -For each committish supplied, `git-describe` will first look for
118 +For each committish supplied, 'git-describe' will first look for
119 a tag which tags exactly that commit. Annotated tags will always
120 be preferred over lightweight tags, and tags with newer dates will
121 always be preferred over tags with older dates. If an exact match
122 is found, its name will be output and searching will stop.
123
124 -If an exact match was not found, `git-describe` will walk back
124 +If an exact match was not found, 'git-describe' will walk back
125 through the commit history to locate an ancestor commit which
126 has been tagged. The ancestor's tag will be output along with an
127 abbreviation of the input committish's SHA1.
Documentation/git-diff-files.txt
+1 -1
@@ -15,7 +15,7 @@ DESCRIPTION
15 Compares the files in the working tree and the index. When paths
16 are specified, compares only those named paths. Otherwise all
17 entries in the index are compared. The output format is the
18 -same as for `git-diff-index` and `git-diff-tree`.
18 +same as for 'git-diff-index' and 'git-diff-tree'.
19
20 OPTIONS
21 -------
Documentation/git-diff-index.txt
+10 -10
@@ -31,7 +31,7 @@ include::diff-options.txt[]
31 -m::
32 By default, files recorded in the index but not checked
33 out are reported as deleted. This flag makes
34 - `git-diff-index` say that all non-checked-out files are up
34 + 'git-diff-index' say that all non-checked-out files are up
35 to date.
36
37 Output format
@@ -50,7 +50,7 @@ Cached Mode
50 If '--cached' is specified, it allows you to ask:
51
52 show me the differences between HEAD and the current index
53 - contents (the ones I'd write using `git-write-tree`)
53 + contents (the ones I'd write using 'git-write-tree')
54
55 For example, let's say that you have worked on your working directory, updated
56 some files in the index and are ready to commit. You want to see exactly
@@ -62,7 +62,7 @@ object and compare it that way, and to do that, you just do
62 Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
63 done an `update-index` to make that effective in the index file.
64 `git diff-files` wouldn't show anything at all, since the index file
65 -matches my working directory. But doing a `git-diff-index` does:
65 +matches my working directory. But doing a 'git-diff-index' does:
66
67 torvalds@ppc970:~/git> git diff-index --cached HEAD
68 -100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
@@ -71,10 +71,10 @@ matches my working directory. But doing a `git-diff-index` does:
71 You can see easily that the above is a rename.
72
73 In fact, `git diff-index --cached` *should* always be entirely equivalent to
74 -actually doing a `git-write-tree` and comparing that. Except this one is much
74 +actually doing a 'git-write-tree' and comparing that. Except this one is much
75 nicer for the case where you just want to check where you are.
76
77 -So doing a `git-diff-index --cached` is basically very useful when you are
77 +So doing a 'git-diff-index --cached' is basically very useful when you are
78 asking yourself "what have I already marked for being committed, and
79 what's the difference to a previous tree".
80
@@ -82,20 +82,20 @@ Non-cached Mode
82 ---------------
83 The "non-cached" mode takes a different approach, and is potentially
84 the more useful of the two in that what it does can't be emulated with
85 -a `git-write-tree` + `git-diff-tree`. Thus that's the default mode.
85 +a 'git-write-tree' + 'git-diff-tree'. Thus that's the default mode.
86 The non-cached version asks the question:
87
88 show me the differences between HEAD and the currently checked out
89 tree - index contents _and_ files that aren't up-to-date
90
91 which is obviously a very useful question too, since that tells you what
92 -you *could* commit. Again, the output matches the `git-diff-tree -r`
92 +you *could* commit. Again, the output matches the 'git-diff-tree -r'
93 output to a tee, but with a twist.
94
95 The twist is that if some file doesn't match the index, we don't have
96 a backing store thing for it, and we use the magic "all-zero" sha1 to
97 show that. So let's say that you have edited `kernel/sched.c`, but
98 -have not actually done a `git-update-index` on it yet - there is no
98 +have not actually done a 'git-update-index' on it yet - there is no
99 "object" associated with the new state, and you get:
100
101 torvalds@ppc970:~/v2.6/linux> git diff-index HEAD
@@ -106,11 +106,11 @@ not up-to-date and may contain new stuff. The all-zero sha1 means that to
106 get the real diff, you need to look at the object in the working directory
107 directly rather than do an object-to-object diff.
108
109 -NOTE: As with other commands of this type, `git-diff-index` does not
109 +NOTE: As with other commands of this type, 'git-diff-index' does not
110 actually look at the contents of the file at all. So maybe
111 `kernel/sched.c` hasn't actually changed, and it's just that you
112 touched it. In either case, it's a note that you need to
113 -`git-update-index` it to make the index be in sync.
113 +'git-update-index' it to make the index be in sync.
114
115 NOTE: You can have a mixture of files show up as "has been updated"
116 and "is still dirty in the working directory" together. You can always
Documentation/git-diff-tree.txt
+5 -5
@@ -20,7 +20,7 @@ Compares the content and mode of the blobs found via two tree objects.
20 If there is only one <tree-ish> given, the commit is compared with its parents
21 (see --stdin below).
22
23 -Note that `git-diff-tree` can use the tree encapsulated in a commit object.
23 +Note that 'git-diff-tree' can use the tree encapsulated in a commit object.
24
25 OPTIONS
26 -------
@@ -58,25 +58,25 @@ behavior. This does not apply to the case where two <tree-ish>
58 separated with a single space are given.
59
60 -m::
61 - By default, `git-diff-tree --stdin` does not show
61 + By default, 'git-diff-tree --stdin' does not show
62 differences for merge commits. With this flag, it shows
63 differences to that commit from all of its parents. See
64 also '-c'.
65
66 -s::
67 - By default, `git-diff-tree --stdin` shows differences,
67 + By default, 'git-diff-tree --stdin' shows differences,
68 either in machine-readable form (without '-p') or in patch
69 form (with '-p'). This output can be suppressed. It is
70 only useful with '-v' flag.
71
72 -v::
73 - This flag causes `git-diff-tree --stdin` to also show
73 + This flag causes 'git-diff-tree --stdin' to also show
74 the commit message before the differences.
75
76 include::pretty-options.txt[]
77
78 --no-commit-id::
79 - `git-diff-tree` outputs a line with the commit ID when
79 + 'git-diff-tree' outputs a line with the commit ID when
80 applicable. This flag suppressed the commit ID output.
81
82 -c::
Documentation/git-fast-export.txt
+4 -4
@@ -13,18 +13,18 @@ SYNOPSIS
13 DESCRIPTION
14 -----------
15 This program dumps the given revisions in a form suitable to be piped
16 -into `git-fast-import`.
16 +into 'git-fast-import'.
17
18 You can use it as a human readable bundle replacement (see
19 linkgit:git-bundle[1]), or as a kind of an interactive
20 -`git-filter-branch`.
20 +'git-filter-branch'.
21
22
23 OPTIONS
24 -------
25 --progress=<n>::
26 Insert 'progress' statements every <n> objects, to be shown by
27 - `git-fast-import` during import.
27 + 'git-fast-import' during import.
28
29 --signed-tags=(verbatim|warn|strip|abort)::
30 Specify how to handle signed tags. Since any transformation
@@ -85,7 +85,7 @@ referenced by that revision range contains the string
85 Limitations
86 -----------
87
88 -Since `git-fast-import` cannot tag trees, you will not be
88 +Since 'git-fast-import' cannot tag trees, you will not be
89 able to export the linux-2.6.git repository completely, as it contains
90 a tag referencing a tree instead of a commit.
91
Documentation/git-fast-import.txt
+10 -10
@@ -15,7 +15,7 @@ DESCRIPTION
15 This program is usually not what the end user wants to run directly.
16 Most end users want to use one of the existing frontend programs,
17 which parses a specific type of foreign source and feeds the contents
18 -stored there to `git-fast-import`.
18 +stored there to 'git-fast-import'.
19
20 fast-import reads a mixed command/data stream from standard input and
21 writes one or more packfiles directly into the current repository.
@@ -24,7 +24,7 @@ updated branch and tag refs, fully updating the current repository
24 with the newly imported data.
25
26 The fast-import backend itself can import into an empty repository (one that
27 -has already been initialized by `git-init`) or incrementally
27 +has already been initialized by 'git-init') or incrementally
28 update an existing populated repository. Whether or not incremental
29 imports are supported from a particular foreign source depends on
30 the frontend program in use.
@@ -82,7 +82,7 @@ OPTIONS
82 This information may be useful after importing projects
83 whose total object set exceeds the 4 GiB packfile limit,
84 as these commits can be used as edge points during calls
85 - to `git-pack-objects`.
85 + to 'git-pack-objects'.
86
87 --quiet::
88 Disable all non-fatal output, making fast-import silent when it
@@ -124,9 +124,9 @@ an ideal situation, given that most conversion tools are throw-away
124
125 Parallel Operation
126 ------------------
127 -Like `git-push` or `git-fetch`, imports handled by fast-import are safe to
127 +Like 'git-push' or 'git-fetch', imports handled by fast-import are safe to
128 run alongside parallel `git repack -a -d` or `git gc` invocations,
129 -or any other Git operation (including `git-prune`, as loose objects
129 +or any other Git operation (including 'git-prune', as loose objects
130 are never used by fast-import).
131
132 fast-import does not lock the branch or tag refs it is actively importing.
@@ -220,7 +220,7 @@ variation in formatting will cause fast-import to reject the value.
220 +
221 An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git
222 parser is accurate, but a little on the lenient side. It is the
223 -same parser used by `git-am` when applying patches
223 +same parser used by 'git-am' when applying patches
224 received from email.
225 +
226 Some malformed strings may be accepted as valid dates. In some of
@@ -256,7 +256,7 @@ timezone.
256 This particular format is supplied as its short to implement and
257 may be useful to a process that wants to create a new commit
258 right now, without needing to use a working directory or
259 -`git-update-index`.
259 +'git-update-index'.
260 +
261 If separate `author` and `committer` commands are used in a `commit`
262 the timestamps may not match, as the system clock will be polled
@@ -654,7 +654,7 @@ recommended, as the frontend does not (easily) have access to the
654 complete set of bytes which normally goes into such a signature.
655 If signing is required, create lightweight tags from within fast-import with
656 `reset`, then create the annotated versions of those tags offline
657 -with the standard `git-tag` process.
657 +with the standard 'git-tag' process.
658
659 `reset`
660 ~~~~~~~
@@ -955,7 +955,7 @@ is not `refs/heads/TAG_FIXUP`).
955
956 When committing fixups, consider using `merge` to connect the
957 commit(s) which are supplying file revisions to the fixup branch.
958 -Doing so will allow tools such as `git-blame` to track
958 +Doing so will allow tools such as 'git-blame' to track
959 through the real commit history and properly annotate the source
960 files.
961
@@ -984,7 +984,7 @@ Repacking Historical Data
984 ~~~~~~~~~~~~~~~~~~~~~~~~~
985 If you are repacking very old imported data (e.g. older than the
986 last year), consider expending some extra CPU time and supplying
987 -\--window=50 (or higher) when you run `git-repack`.
987 +\--window=50 (or higher) when you run 'git-repack'.
988 This will take longer, but will also produce a smaller packfile.
989 You only need to expend the effort once, and everyone using your
990 project will benefit from the smaller repository.
Documentation/git-fetch-pack.txt
+7 -7
@@ -12,14 +12,14 @@ SYNOPSIS
12
13 DESCRIPTION
14 -----------
15 -Usually you would want to use `git-fetch`, which is a
15 +Usually you would want to use 'git-fetch', which is a
16 higher level wrapper of this command, instead.
17
18 -Invokes `git-upload-pack` on a possibly remote repository
18 +Invokes 'git-upload-pack' on a possibly remote repository
19 and asks it to send objects missing from this repository, to
20 update the named heads. The list of commits available locally
21 is found out by scanning local $GIT_DIR/refs/ and sent to
22 -`git-upload-pack` running on the other end.
22 +'git-upload-pack' running on the other end.
23
24 This command degenerates to download everything to complete the
25 asked refs from the remote side when the local side does not
@@ -33,12 +33,12 @@ OPTIONS
33
34 -q::
35 --quiet::
36 - Pass '-q' flag to `git-unpack-objects`; this makes the
36 + Pass '-q' flag to 'git-unpack-objects'; this makes the
37 cloning process less verbose.
38
39 -k::
40 --keep::
41 - Do not invoke `git-unpack-objects` on received data, but
41 + Do not invoke 'git-unpack-objects' on received data, but
42 create a single packfile out of it instead, and store it
43 in the object database. If provided twice then the pack is
44 locked against repacking.
@@ -54,7 +54,7 @@ OPTIONS
54 otherwise determine the tags this option made available.
55
56 --upload-pack=<git-upload-pack>::
57 - Use this to specify the path to `git-upload-pack` on the
57 + Use this to specify the path to 'git-upload-pack' on the
58 remote side, if is not found on your $PATH.
59 Installations of sshd ignores the user's environment
60 setup scripts for login shells (e.g. .bash_profile) and
@@ -79,7 +79,7 @@ OPTIONS
79
80 <host>::
81 A remote host that houses the repository. When this
82 - part is specified, `git-upload-pack` is invoked via
82 + part is specified, 'git-upload-pack' is invoked via
83 ssh.
84
85 <directory>::
Documentation/git-fetch.txt
+1 -1
@@ -18,7 +18,7 @@ the objects necessary to complete them.
18
19 The ref names and their object names of fetched refs are stored
20 in `.git/FETCH_HEAD`. This information is left for a later merge
21 -operation done by `git-merge`.
21 +operation done by 'git-merge'.
22
23 When <refspec> stores the fetched result in tracking branches,
24 the tags that point at these branches are automatically
Documentation/git-filter-branch.txt
+7 -7
@@ -108,7 +108,7 @@ OPTIONS
108 --commit-filter <command>::
109 This is the filter for performing the commit.
110 If this filter is specified, it will be called instead of the
111 - `git-commit-tree` command, with arguments of the form
111 + 'git-commit-tree' command, with arguments of the form
112 "<TREE_ID> [-p <PARENT_COMMIT_ID>]..." and the log message on
113 stdin. The commit id is expected on stdout.
114 +
@@ -119,7 +119,7 @@ have all of them as parents.
119 You can use the 'map' convenience function in this filter, and other
120 convenience functions, too. For example, calling 'skip_commit "$@"'
121 will leave out the current commit (but not its changes! If you want
122 -that, use `git-rebase` instead).
122 +that, use 'git-rebase' instead).
123
124 --tag-name-filter <command>::
125 This is the filter for rewriting tag names. When passed,
@@ -163,13 +163,13 @@ to other tags will be rewritten to point to the underlying commit.
163
164 -f::
165 --force::
166 - `git-filter-branch` refuses to start with an existing temporary
166 + 'git-filter-branch' refuses to start with an existing temporary
167 directory or when there are already refs starting with
168 'refs/original/', unless forced.
169
170 <rev-list-options>::
171 When options are given after the new branch name, they will
172 - be passed to `git-rev-list`. Only commits in the resulting
172 + be passed to 'git-rev-list'. Only commits in the resulting
173 output will be filtered, although the filtered commits can still
174 reference parents which are outside of that set.
175
@@ -255,7 +255,7 @@ and all children of the merge will become merge commits with P1,P2
255 as their parents instead of the merge commit.
256
257 You can rewrite the commit log messages using `--msg-filter`. For
258 -example, `git-svn-id` strings in a repository created by `git-svn` can
258 +example, 'git-svn-id' strings in a repository created by 'git-svn' can
259 be removed this way:
260
261 -------------------------------------------------------
@@ -266,13 +266,13 @@ git filter-branch --msg-filter '
266
267 To restrict rewriting to only part of the history, specify a revision
268 range in addition to the new branch name. The new branch name will
269 -point to the top-most revision that a `git-rev-list` of this range
269 +point to the top-most revision that a 'git-rev-list' of this range
270 will print.
271
272 *NOTE* the changes introduced by the commits, and which are not reverted
273 by subsequent commits, will still be in the rewritten branch. If you want
274 to throw out _changes_ together with the commits, you should use the
275 -interactive mode of `git-rebase`.
275 +interactive mode of 'git-rebase'.
276
277
278 Consider this history:
Documentation/git-fmt-merge-msg.txt
+2 -2
@@ -16,10 +16,10 @@ DESCRIPTION
16 -----------
17 Takes the list of merged objects on stdin and produces a suitable
18 commit message to be used for the merge commit, usually to be
19 -passed as the '<merge-message>' argument of `git-merge`.
19 +passed as the '<merge-message>' argument of 'git-merge'.
20
21 This script is intended mostly for internal use by scripts
22 -automatically invoking `git-merge`.
22 +automatically invoking 'git-merge'.
23
24 OPTIONS
25 -------
Documentation/git-for-each-ref.txt
+1 -1
@@ -79,7 +79,7 @@ objecttype::
79 The type of the object (`blob`, `tree`, `commit`, `tag`).
80
81 objectsize::
82 - The size of the object (the same as `git-cat-file -s` reports).
82 + The size of the object (the same as 'git-cat-file -s' reports).
83
84 objectname::
85 The object name (aka SHA-1).
Documentation/git-format-patch.txt
+3 -3
@@ -27,7 +27,7 @@ DESCRIPTION
27 Prepare each commit with its patch in
28 one file per commit, formatted to resemble UNIX mailbox format.
29 The output of this command is convenient for e-mail submission or
30 -for use with `git-am`.
30 +for use with 'git-am'.
31
32 There are two ways to specify which commits to operate on.
33
@@ -61,7 +61,7 @@ they are created in the current working directory.
61 If -n is specified, instead of "[PATCH] Subject", the first line
62 is formatted as "[PATCH n/m] Subject".
63
64 -If given --thread, `git-format-patch` will generate In-Reply-To and
64 +If given --thread, 'git-format-patch' will generate In-Reply-To and
65 References headers to make the second and subsequent patch mails appear
66 as replies to the first mail; this also generates a Message-Id header to
67 reference.
@@ -187,7 +187,7 @@ EXAMPLES
187 --------
188
189 * Extract commits between revisions R1 and R2, and apply them on top of
190 -the current branch using `git-am` to cherry-pick them:
190 +the current branch using 'git-am' to cherry-pick them:
191 +
192 ------------
193 $ git format-patch -k --stdout R1..R2 | git am -3 -k
Documentation/git-fsck.txt
+2 -2
@@ -21,7 +21,7 @@ OPTIONS
21 <object>::
22 An object to treat as the head of an unreachability trace.
23 +
24 -If no objects are given, `git-fsck` defaults to using the
24 +If no objects are given, 'git-fsck' defaults to using the
25 index file, all SHA1 references in .git/refs/*, and all reflogs (unless
26 --no-reflogs is given) as heads.
27
@@ -83,7 +83,7 @@ So for example
83
84 will do quite a _lot_ of verification on the tree. There are a few
85 extra validity tests to be added (make sure that tree objects are
86 -sorted properly etc), but on the whole if `git-fsck` is happy, you
86 +sorted properly etc), but on the whole if 'git-fsck' is happy, you
87 do have a valid tree.
88
89 Any corrupt objects you will have to find in backups or other archives
Documentation/git-gc.txt
+10 -10
@@ -15,13 +15,13 @@ DESCRIPTION
15 Runs a number of housekeeping tasks within the current repository,
16 such as compressing file revisions (to reduce disk space and increase
17 performance) and removing unreachable objects which may have been
18 -created from prior invocations of `git-add`.
18 +created from prior invocations of 'git-add'.
19
20 Users are encouraged to run this task on a regular basis within
21 each repository to maintain good disk space utilization and good
22 operating performance.
23
24 -Some git commands may automatically run `git-gc`; see the `--auto` flag
24 +Some git commands may automatically run 'git-gc'; see the `--auto` flag
25 below for details. If you know what you're doing and all you want is to
26 disable this behavior permanently without further considerations, just do:
27
@@ -33,15 +33,15 @@ OPTIONS
33 -------
34
35 --aggressive::
36 - Usually `git-gc` runs very quickly while providing good disk
36 + Usually 'git-gc' runs very quickly while providing good disk
37 space utilization and performance. This option will cause
38 - `git-gc` to more aggressively optimize the repository at the expense
38 + 'git-gc' to more aggressively optimize the repository at the expense
39 of taking much more time. The effects of this optimization are
40 persistent, so this option only needs to be used occasionally; every
41 few hundred changesets or so.
42
43 --auto::
44 - With this option, `git-gc` checks whether any housekeeping is
44 + With this option, 'git-gc' checks whether any housekeeping is
45 required; if not, it exits without performing any work.
46 Some git commands run `git gc --auto` after performing
47 operations that could create many loose objects.
@@ -50,13 +50,13 @@ Housekeeping is required if there are too many loose objects or
50 too many packs in the repository. If the number of loose objects
51 exceeds the value of the `gc.auto` configuration variable, then
52 all loose objects are combined into a single pack using
53 -`git-repack -d -l`. Setting the value of `gc.auto` to 0
53 +'git-repack -d -l'. Setting the value of `gc.auto` to 0
54 disables automatic packing of loose objects.
55 +
56 If the number of packs exceeds the value of `gc.autopacklimit`,
57 then existing packs (except those marked with a `.keep` file)
58 are consolidated into a single pack by using the `-A` option of
59 -`git-repack`. Setting `gc.autopacklimit` to 0 disables
59 +'git-repack'. Setting `gc.autopacklimit` to 0 disables
60 automatic consolidation of packs.
61
62 --quiet::
@@ -89,7 +89,7 @@ how long records of conflicted merge you have not resolved are
89 kept. This defaults to 15 days.
90
91 The optional configuration variable 'gc.packrefs' determines if
92 -`git-gc` runs `git-pack-refs`. This can be set to "nobare" to enable
92 +'git-gc' runs 'git-pack-refs'. This can be set to "nobare" to enable
93 it within all non-bare repos or it can be set to a boolean value.
94 This defaults to true.
95
@@ -108,10 +108,10 @@ default is "2 weeks ago".
108 Notes
109 -----
110
111 -`git-gc` tries very hard to be safe about the garbage it collects. In
111 +'git-gc' tries very hard to be safe about the garbage it collects. In
112 particular, it will keep not only objects referenced by your current set
113 of branches and tags, but also objects referenced by the index, remote
114 -tracking branches, refs saved by `git-filter-branch` in
114 +tracking branches, refs saved by 'git-filter-branch' in
115 refs/original/, or reflogs (which may references commits in branches
116 that were later amended or rewound).
117
Documentation/git-get-tar-commit-id.txt
+3 -3
@@ -14,12 +14,12 @@ SYNOPSIS
14 DESCRIPTION
15 -----------
16 Acts as a filter, extracting the commit ID stored in archives created by
17 -`git-archive`. It reads only the first 1024 bytes of input, thus its
17 +'git-archive'. It reads only the first 1024 bytes of input, thus its
18 runtime is not influenced by the size of <tarfile> very much.
19
20 -If no commit ID is found, `git-get-tar-commit-id` quietly exists with a
20 +If no commit ID is found, 'git-get-tar-commit-id' quietly exists with a
21 return code of 1. This can happen if <tarfile> had not been created
22 -using `git-archive` or if the first parameter of `git-archive` had been
22 +using 'git-archive' or if the first parameter of 'git-archive' had been
23 a tree ID instead of a commit ID or tag.
24
25
Documentation/git-grep.txt
+1 -1
@@ -91,7 +91,7 @@ OPTIONS
91 --files-without-match::
92 Instead of showing every matched line, show only the
93 names of files that contain (or do not contain) matches.
94 - For better compatibility with `git-diff`, --name-only is a
94 + For better compatibility with 'git-diff', --name-only is a
95 synonym for --files-with-matches.
96
97 -c::
Documentation/git-gui.txt
+10 -10
@@ -11,19 +11,19 @@ SYNOPSIS
11
12 DESCRIPTION
13 -----------
14 -A Tcl/Tk based graphical user interface to Git. `git-gui` focuses
14 +A Tcl/Tk based graphical user interface to Git. 'git-gui' focuses
15 on allowing users to make changes to their repository by making
16 new commits, amending existing ones, creating branches, performing
17 local merges, and fetching/pushing to remote repositories.
18
19 -Unlike `gitk`, `git-gui` focuses on commit generation
19 +Unlike `gitk`, 'git-gui' focuses on commit generation
20 and single file annotation and does not show project history.
21 It does however supply menu actions to start a `gitk` session from
22 -within `git-gui`.
22 +within 'git-gui'.
23
24 -`git-gui` is known to work on all popular UNIX systems, Mac OS X,
24 +'git-gui' is known to work on all popular UNIX systems, Mac OS X,
25 and Windows (under both Cygwin and MSYS). To the extent possible
26 -OS specific user interface guidelines are followed, making `git-gui`
26 +OS specific user interface guidelines are followed, making 'git-gui'
27 a fairly native interface for users.
28
29 COMMANDS
@@ -38,13 +38,13 @@ browser::
38 browser are opened in the blame viewer.
39
40 citool::
41 - Start `git-gui` and arrange to make exactly one commit before
41 + Start 'git-gui' and arrange to make exactly one commit before
42 exiting and returning to the shell. The interface is limited
43 to only commit actions, slightly reducing the application's
44 startup time and simplifying the menubar.
45
46 version::
47 - Display the currently running version of `git-gui`.
47 + Display the currently running version of 'git-gui'.
48
49
50 Examples
@@ -84,15 +84,15 @@ SEE ALSO
84 linkgit:gitk[1]::
85 The git repository browser. Shows branches, commit history
86 and file differences. gitk is the utility started by
87 - `git-gui`'s Repository Visualize actions.
87 + 'git-gui''s Repository Visualize actions.
88
89 Other
90 -----
91 -`git-gui` is actually maintained as an independent project, but stable
91 +'git-gui' is actually maintained as an independent project, but stable
92 versions are distributed as part of the Git suite for the convenience
93 of end users.
94
95 -A `git-gui` development repository can be obtained from:
95 +A 'git-gui' development repository can be obtained from:
96
97 git clone git://repo.or.cz/git-gui.git
98
Documentation/git-hash-object.txt
+1 -1
@@ -16,7 +16,7 @@ Computes the object ID value for an object with specified type
16 with the contents of the named file (which can be outside of the
17 work tree), and optionally writes the resulting object into the
18 object database. Reports its object ID to its standard output.
19 -This is used by `git-cvsimport` to update the index
19 +This is used by 'git-cvsimport' to update the index
20 without modifying files in the work tree. When <type> is not
21 specified, it defaults to "blob".
22
Documentation/git-help.txt
+3 -3
@@ -55,8 +55,8 @@ other display programs (see below).
55 +
56 The web browser can be specified using the configuration variable
57 'help.browser', or 'web.browser' if the former is not set. If none of
58 -these config variables is set, the `git-web--browse` helper script
59 -(called by `git-help`) will pick a suitable default. See
58 +these config variables is set, the 'git-web--browse' helper script
59 +(called by 'git-help') will pick a suitable default. See
60 linkgit:git-web--browse[1] for more information about this.
61
62 CONFIGURATION VARIABLES
@@ -67,7 +67,7 @@ help.format
67
68 If no command line option is passed, the 'help.format' configuration
69 variable will be checked. The following values are supported for this
70 -variable; they make `git-help` behave as their corresponding command
70 +variable; they make 'git-help' behave as their corresponding command
71 line option:
72
73 * "man" corresponds to '-m|--man',
Documentation/git-http-fetch.txt
+1 -1
@@ -35,7 +35,7 @@ commit-id::
35
36 --stdin::
37 Instead of a commit id on the command line (which is not expected in this
38 - case), `git-http-fetch` expects lines on stdin in the format
38 + case), 'git-http-fetch' expects lines on stdin in the format
39
40 <commit-id>['\t'<filename-as-in--w>]
41
Documentation/git-imap-send.txt
+1 -1
@@ -26,7 +26,7 @@ git format-patch --signoff --stdout --attach origin | git imap-send
26 CONFIGURATION
27 -------------
28
29 -`git-imap-send` requires the following values in the repository
29 +'git-imap-send' requires the following values in the repository
30 configuration file (shown with examples):
31
32 ..........................
Documentation/git-index-pack.txt
+4 -4
@@ -43,10 +43,10 @@ OPTIONS
43 a default name determined from the pack content. If
44 <pack-file> is not specified consider using --keep to
45 prevent a race condition between this process and
46 - `git-repack`.
46 + 'git-repack'.
47
48 --fix-thin::
49 - It is possible for `git-pack-objects` to build
49 + It is possible for 'git-pack-objects' to build
50 "thin" pack, which records objects in deltified form based on
51 objects not included in the pack to reduce network traffic.
52 Those objects are expected to be present on the receiving end
@@ -59,7 +59,7 @@ OPTIONS
59 Before moving the index into its final destination
60 create an empty .keep file for the associated pack file.
61 This option is usually necessary with --stdin to prevent a
62 - simultaneous `git-repack` process from deleting
62 + simultaneous 'git-repack' process from deleting
63 the newly constructed pack and index before refs can be
64 updated to use objects contained in the pack.
65
@@ -86,7 +86,7 @@ Once the index has been created, the list of object names is sorted
86 and the SHA1 hash of that list is printed to stdout. If --stdin was
87 also used then this is prefixed by either "pack\t", or "keep\t" if a
88 new .keep file was successfully created. This is useful to remove a
89 -.keep file used as a lock to prevent the race with `git-repack`
89 +.keep file used as a lock to prevent the race with 'git-repack'
90 mentioned above.
91
92
Documentation/git-init.txt
+3 -3
@@ -86,11 +86,11 @@ If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY`
86 environment variable then the sha1 directories are created underneath -
87 otherwise the default `$GIT_DIR/objects` directory is used.
88
89 -Running `git-init` in an existing repository is safe. It will not overwrite
90 -things that are already there. The primary reason for rerunning `git-init`
89 +Running 'git-init' in an existing repository is safe. It will not overwrite
90 +things that are already there. The primary reason for rerunning 'git-init'
91 is to pick up newly added templates.
92
93 -Note that `git-init` is the same as `git-init-db`. The command
93 +Note that 'git-init' is the same as 'git-init-db'. The command
94 was primarily meant to initialize the object database, but over
95 time it has become responsible for setting up the other aspects
96 of the repository, such as installing the default hooks and
Documentation/git-instaweb.txt
+1 -1
@@ -44,7 +44,7 @@ OPTIONS
44 -b::
45 --browser::
46 The web browser that should be used to view the gitweb
47 - page. This will be passed to the `git-web--browse` helper
47 + page. This will be passed to the 'git-web--browse' helper
48 script along with the URL of the gitweb instance. See
49 linkgit:git-web--browse[1] for more information about this. If
50 the script fails, the URL will be printed to stdout.
Documentation/git-log.txt
+2 -2
@@ -14,9 +14,9 @@ DESCRIPTION
14 -----------
15 Shows the commit logs.
16
17 -The command takes options applicable to the `git-rev-list`
17 +The command takes options applicable to the 'git-rev-list'
18 command to control what is shown and how, and options applicable to
19 -the `git-diff-*` commands to control how the changes
19 +the 'git-diff-*' commands to control how the changes
20 each commit introduces are shown.
21
22
Documentation/git-ls-files.txt
+3 -3
@@ -143,7 +143,7 @@ which case it outputs:
143
144 [<tag> ]<mode> <object> <stage> <file>
145
146 -`git-ls-files --unmerged` and `git-ls-files --stage` can be used to examine
146 +'git-ls-files --unmerged' and 'git-ls-files --stage' can be used to examine
147 detailed information on unmerged paths.
148
149 For an unmerged path, instead of recording a single mode/SHA1 pair,
@@ -160,7 +160,7 @@ respectively.
160 Exclude Patterns
161 ----------------
162
163 -`git-ls-files` can use a list of "exclude patterns" when
163 +'git-ls-files' can use a list of "exclude patterns" when
164 traversing the directory tree and finding files to show when the
165 flags --others or --ignored are specified. linkgit:gitignore[5]
166 specifies the format of exclude patterns.
@@ -176,7 +176,7 @@ These exclude patterns come from these places, in order:
176 in the same order they appear in the file.
177
178 3. command line flag --exclude-per-directory=<name> specifies
179 - a name of the file in each directory `git-ls-files`
179 + a name of the file in each directory 'git-ls-files'
180 examines, normally `.gitignore`. Files in deeper
181 directories take precedence. Patterns are ordered in the
182 same order they appear in the files.
Documentation/git-ls-remote.txt
+1 -1
@@ -31,7 +31,7 @@ OPTIONS
31
32 -u <exec>::
33 --upload-pack=<exec>::
34 - Specify the full path of `git-upload-pack` on the remote
34 + Specify the full path of 'git-upload-pack' on the remote
35 host. This allows listing references from repositories accessed via
36 SSH and where the SSH daemon does not use the PATH configured by the
37 user.
Documentation/git-mailinfo.txt
+2 -2
@@ -16,7 +16,7 @@ DESCRIPTION
16 Reading a single e-mail message from the standard input, and
17 writes the commit log message in <msg> file, and the patches in
18 <patch> file. The author name, e-mail and e-mail subject are
19 -written out to the standard output to be used by `git-am`
19 +written out to the standard output to be used by 'git-am'
20 to create a commit. It is usually not necessary to use this
21 command directly. See linkgit:git-am[1] instead.
22
@@ -30,7 +30,7 @@ OPTIONS
30 whitespaces, (3) '[' up to ']', typically '[PATCH]', and
31 then prepends "[PATCH] ". This flag forbids this
32 munging, and is most useful when used to read back
33 - `git-format-patch -k` output.
33 + 'git-format-patch -k' output.
34
35 -u::
36 The commit log message, author name and author email are
Documentation/git-merge-base.txt
+2 -2
@@ -13,7 +13,7 @@ SYNOPSIS
13 DESCRIPTION
14 -----------
15
16 -`git-merge-base` finds as good a common ancestor as possible between
16 +'git-merge-base' finds as good a common ancestor as possible between
17 the two commits. That is, given two commits A and B, `git merge-base A
18 B` will output a commit which is reachable from both A and B through
19 the parent relationship.
@@ -21,7 +21,7 @@ the parent relationship.
21 Given a selection of equally good common ancestors it should not be
22 relied on to decide in any particular way.
23
24 -The `git-merge-base` algorithm is still in flux - use the source...
24 +The 'git-merge-base' algorithm is still in flux - use the source...
25
26 OPTIONS
27 -------
Documentation/git-merge-file.txt
+5 -5
@@ -15,15 +15,15 @@ SYNOPSIS
15
16 DESCRIPTION
17 -----------
18 -`git-file-merge` incorporates all changes that lead from the `<base-file>`
18 +'git-file-merge' incorporates all changes that lead from the `<base-file>`
19 to `<other-file>` into `<current-file>`. The result ordinarily goes into
20 -`<current-file>`. `git-merge-file` is useful for combining separate changes
20 +`<current-file>`. 'git-merge-file' is useful for combining separate changes
21 to an original. Suppose `<base-file>` is the original, and both
22 `<current-file>` and `<other-file>` are modifications of `<base-file>`.
23 -Then `git-merge-file` combines both changes.
23 +Then 'git-merge-file' combines both changes.
24
25 A conflict occurs if both `<current-file>` and `<other-file>` have changes
26 -in a common segment of lines. If a conflict is found, `git-merge-file`
26 +in a common segment of lines. If a conflict is found, 'git-merge-file'
27 normally outputs a warning and brackets the conflict with <<<<<<< and
28 >>>>>>> lines. A typical conflict will look like this:
29
@@ -39,7 +39,7 @@ the alternatives.
39 The exit value of this program is negative on error, and the number of
40 conflicts otherwise. If the merge was clean, the exit value is 0.
41
42 -`git-merge-file` is designed to be a minimal clone of RCS `merge`; that is, it
42 +'git-merge-file' is designed to be a minimal clone of RCS `merge`; that is, it
43 implements all of RCS merge's functionality which is needed by
44 linkgit:git[1].
45
Documentation/git-merge-index.txt
+4 -4
@@ -36,14 +36,14 @@ OPTIONS
36 failure usually indicates conflicts during merge). This is for
37 porcelains which might want to emit custom messages.
38
39 -If `git-merge-index` is called with multiple <file>s (or -a) then it
39 +If 'git-merge-index' is called with multiple <file>s (or -a) then it
40 processes them in turn only stopping if merge returns a non-zero exit
41 code.
42
43 Typically this is run with a script calling git's imitation of
44 the 'merge' command from the RCS package.
45
46 -A sample script called `git-merge-one-file` is included in the
46 +A sample script called 'git-merge-one-file' is included in the
47 distribution.
48
49 ALERT ALERT ALERT! The git "merge object order" is different from the
@@ -68,10 +68,10 @@ or
68 This is added AA in the branch B.
69 fatal: merge program failed
70
71 -where the latter example shows how `git-merge-index` will stop trying to
71 +where the latter example shows how 'git-merge-index' will stop trying to
72 merge once anything has returned an error (i.e., `cat` returned an error
73 for the AA file, because it didn't exist in the original, and thus
74 -`git-merge-index` didn't even try to merge the MM thing).
74 +'git-merge-index' didn't even try to merge the MM thing).
75
76 Author
77 ------
Documentation/git-merge-one-file.txt
+2 -2
@@ -12,8 +12,8 @@ SYNOPSIS
12
13 DESCRIPTION
14 -----------
15 -This is the standard helper program to use with `git-merge-index`
16 -to resolve a merge after the trivial merge done with `git-read-tree -m`.
15 +This is the standard helper program to use with 'git-merge-index'
16 +to resolve a merge after the trivial merge done with 'git-read-tree -m'.
17
18 Author
19 ------
Documentation/git-merge.txt
+8 -8
@@ -29,8 +29,8 @@ include::merge-options.txt[]
29
30 -m <msg>::
31 The commit message to be used for the merge commit (in case
32 - it is created). The `git-fmt-merge-msg` script can be used
33 - to give a good default for automated `git-merge` invocations.
32 + it is created). The 'git-fmt-merge-msg' script can be used
33 + to give a good default for automated 'git-merge' invocations.
34
35 <remote>::
36 Other branch head merged into our branch. You need at
@@ -41,7 +41,7 @@ include::merge-strategies.txt[]
41
42
43 If you tried a merge which resulted in a complex conflicts and
44 -would want to start over, you can recover with `git-reset`.
44 +would want to start over, you can recover with 'git-reset'.
45
46 CONFIGURATION
47 -------------
@@ -49,7 +49,7 @@ include::merge-config.txt[]
49
50 branch.<name>.mergeoptions::
51 Sets default options for merging into branch <name>. The syntax and
52 - supported options are equal to that of `git-merge`, but option values
52 + supported options are equal to that of 'git-merge', but option values
53 containing whitespace characters are currently not supported.
54
55 HOW MERGE WORKS
@@ -84,7 +84,7 @@ with `git pull remote rbranch:lbranch`, but your working tree,
84 `.git/HEAD` pointer and index file are left intact).
85
86 You may have local modifications in the working tree files. In
87 -other words, `git-diff` is allowed to report changes.
87 +other words, 'git-diff' is allowed to report changes.
88 However, the merge uses your working tree as the working area,
89 and in order to prevent the merge operation from losing such
90 changes, it makes sure that they do not interfere with the
@@ -140,14 +140,14 @@ After seeing a conflict, you can do two things:
140
141 * Decide not to merge. The only clean-up you need are to reset
142 the index file to the `HEAD` commit to reverse 2. and to clean
143 - up working tree changes made by 2. and 3.; `git-reset` can
143 + up working tree changes made by 2. and 3.; 'git-reset' can
144 be used for this.
145
146 * Resolve the conflicts. `git diff` would report only the
147 conflicting paths because of the above 2. and 3. Edit the
148 - working tree files into a desirable shape, `git-add` or `git-rm`
148 + working tree files into a desirable shape, 'git-add' or 'git-rm'
149 them, to make the index file contain what the merge result
150 - should be, and run `git-commit` to commit the result.
150 + should be, and run 'git-commit' to commit the result.
151
152
153 SEE ALSO
Documentation/git-mergetool.txt
+8 -8
@@ -13,11 +13,11 @@ DESCRIPTION
13 -----------
14
15 Use `git mergetool` to run one of several merge utilities to resolve
16 -merge conflicts. It is typically run after `git-merge`.
16 +merge conflicts. It is typically run after 'git-merge'.
17
18 If one or more <file> parameters are given, the merge tool program will
19 be run to resolve differences on each file. If no <file> names are
20 -specified, `git-mergetool` will run the merge tool program on every file
20 +specified, 'git-mergetool' will run the merge tool program on every file
21 with merge conflicts.
22
23 OPTIONS
@@ -27,23 +27,23 @@ OPTIONS
27 Valid merge tools are:
28 kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
29 +
30 -If a merge resolution program is not specified, `git-mergetool`
30 +If a merge resolution program is not specified, 'git-mergetool'
31 will use the configuration variable `merge.tool`. If the
32 -configuration variable `merge.tool` is not set, `git-mergetool`
32 +configuration variable `merge.tool` is not set, 'git-mergetool'
33 will pick a suitable default.
34 +
35 You can explicitly provide a full path to the tool by setting the
36 configuration variable `mergetool.<tool>.path`. For example, you
37 can configure the absolute path to kdiff3 by setting
38 -`mergetool.kdiff3.path`. Otherwise, `git-mergetool` assumes the
38 +`mergetool.kdiff3.path`. Otherwise, 'git-mergetool' assumes the
39 tool is available in PATH.
40 +
41 Instead of running one of the known merge tool programs
42 -`git-mergetool` can be customized to run an alternative program
42 +'git-mergetool' can be customized to run an alternative program
43 by specifying the command line to invoke in a configration
44 variable `mergetool.<tool>.cmd`.
45 +
46 -When `git-mergetool` is invoked with this tool (either through the
46 +When 'git-mergetool' is invoked with this tool (either through the
47 `-t` or `--tool` option or the `merge.tool` configuration
48 variable) the configured command line will be invoked with `$BASE`
49 set to the name of a temporary file containing the common base for
@@ -57,7 +57,7 @@ merge resolution.
57 If the custom merge tool correctly indicates the success of a
58 merge resolution with its exit code then the configuration
59 variable `mergetool.<tool>.trustExitCode` can be set to `true`.
60 -Otherwise, `git-mergetool` will prompt the user to indicate the
60 +Otherwise, 'git-mergetool' will prompt the user to indicate the
61 success of the resolution after the custom tool has exited.
62
63 Author
Documentation/git-name-rev.txt
+3 -3
@@ -15,7 +15,7 @@ SYNOPSIS
15 DESCRIPTION
16 -----------
17 Finds symbolic names suitable for human digestion for revisions given in any
18 -format parsable by `git-rev-parse`.
18 +format parsable by 'git-rev-parse'.
19
20
21 OPTIONS
@@ -38,7 +38,7 @@ OPTIONS
38 Instead of printing both the SHA-1 and the name, print only
39 the name. If given with --tags the usual tag prefix of
40 "tags/" is also omitted from the name, matching the output
41 - of `git-describe` more closely. This option
41 + of 'git-describe' more closely. This option
42 cannot be combined with --stdin.
43
44 --no-undefined::
@@ -56,7 +56,7 @@ wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
56 Of course, you look into the commit, but that only tells you what happened, but
57 not the context.
58
59 -Enter `git-name-rev`:
59 +Enter 'git-name-rev':
60
61 ------------
62 % git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
Documentation/git-pack-objects.txt
+3 -3
@@ -30,7 +30,7 @@ Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
30 any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
31 enables git to read from such an archive.
32
33 -The `git-unpack-objects` command can read the packed archive and
33 +The 'git-unpack-objects' command can read the packed archive and
34 expand the objects contained in the pack into "one-file
35 one-object" format; this is typically done by the smart-pull
36 commands when a pack is created on-the-fly for efficient network
@@ -59,7 +59,7 @@ base-name::
59 --revs::
60 Read the revision arguments from the standard input, instead of
61 individual object names. The revision arguments are processed
62 - the same way as `git-rev-list` with the `--objects` flag
62 + the same way as 'git-rev-list' with the `--objects` flag
63 uses its `commit` arguments to build the list of objects it
64 outputs. The objects on the resulting list are packed.
65
@@ -170,7 +170,7 @@ base-name::
170 A packed archive can express base object of a delta as
171 either 20-byte object name or as an offset in the
172 stream, but older version of git does not understand the
173 - latter. By default, `git-pack-objects` only uses the
173 + latter. By default, 'git-pack-objects' only uses the
174 former format for better compatibility. This option
175 allows the command to use the latter format for
176 compactness. Depending on the average delta chain
Documentation/git-pack-redundant.txt
+1 -1
@@ -16,7 +16,7 @@ This program computes which packs in your repository
16 are redundant. The output is suitable for piping to
17 `xargs rm` if you are in the root of the repository.
18
19 -`git-pack-redundant` accepts a list of objects on standard input. Any objects
19 +'git-pack-redundant' accepts a list of objects on standard input. Any objects
20 given will be ignored when checking which packs are required. This makes the
21 following command useful when wanting to remove packs which contain unreachable
22 objects.
Documentation/git-parse-remote.txt
+1 -1
@@ -32,7 +32,7 @@ get_remote_refs_for_fetch::
32 get_remote_refs_for_push::
33 Given the list of user-supplied `<repo> <refspec>...`,
34 return the list of refs to push in a form suitable to be
35 - fed to the `git-send-pack` command. When `<refspec>...`
35 + fed to the 'git-send-pack' command. When `<refspec>...`
36 is empty the returned list of refs consists of the
37 defaults for the given `<repo>`, if specified in
38 `$GIT_DIR/remotes/`.
Documentation/git-patch-id.txt
+1 -1
@@ -18,7 +18,7 @@ ID" are almost guaranteed to be the same thing.
18
19 IOW, you can use this thing to look for likely duplicate commits.
20
21 -When dealing with `git-diff-tree` output, it takes advantage of
21 +When dealing with 'git-diff-tree' output, it takes advantage of
22 the fact that the patch is prefixed with the object name of the
23 commit, and outputs two 40-byte hexadecimal string. The first
24 string is the patch ID, and the second string is the commit ID.
Documentation/git-peek-remote.txt
+3 -3
@@ -12,12 +12,12 @@ SYNOPSIS
12
13 DESCRIPTION
14 -----------
15 -This command is deprecated; use `git-ls-remote` instead.
15 +This command is deprecated; use 'git-ls-remote' instead.
16
17 OPTIONS
18 -------
19 --upload-pack=<git-upload-pack>::
20 - Use this to specify the path to `git-upload-pack` on the
20 + Use this to specify the path to 'git-upload-pack' on the
21 remote side, if it is not found on your $PATH. Some
22 installations of sshd ignores the user's environment
23 setup scripts for login shells (e.g. .bash_profile) and
@@ -30,7 +30,7 @@ OPTIONS
30
31 <host>::
32 A remote host that houses the repository. When this
33 - part is specified, `git-upload-pack` is invoked via
33 + part is specified, 'git-upload-pack' is invoked via
34 ssh.
35
36 <directory>::
Documentation/git-prune.txt
+7 -7
@@ -13,16 +13,16 @@ SYNOPSIS
13 DESCRIPTION
14 -----------
15
16 -NOTE: In most cases, users should run `git-gc`, which calls
17 -`git-prune`. See the section "NOTES", below.
16 +NOTE: In most cases, users should run 'git-gc', which calls
17 +'git-prune'. See the section "NOTES", below.
18
19 -This runs `git-fsck --unreachable` using all the refs
19 +This runs 'git-fsck --unreachable' using all the refs
20 available in `$GIT_DIR/refs`, optionally with additional set of
21 objects specified on the command line, and prunes all unpacked
22 objects unreachable from any of these head objects from the object database.
23 In addition, it
24 prunes the unpacked objects that are also found in packs by
25 -running `git-prune-packed`.
25 +running 'git-prune-packed'.
26
27 Note that unreachable, packed objects will remain. If this is
28 not desired, see linkgit:git-repack[1].
@@ -59,12 +59,12 @@ $ git prune $(cd ../another && $(git rev-parse --all))
59 Notes
60 -----
61
62 -In most cases, users will not need to call `git-prune` directly, but
63 -should instead call `git-gc`, which handles pruning along with
62 +In most cases, users will not need to call 'git-prune' directly, but
63 +should instead call 'git-gc', which handles pruning along with
64 many other housekeeping tasks.
65
66 For a description of which objects are considered for pruning, see
67 -`git-fsck`'s --unreachable option.
67 +'git-fsck''s --unreachable option.
68
69 SEE ALSO
70 --------
Documentation/git-pull.txt
+5 -5
@@ -13,16 +13,16 @@ SYNOPSIS
13
14 DESCRIPTION
15 -----------
16 -Runs `git-fetch` with the given parameters, and calls `git-merge`
16 +Runs 'git-fetch' with the given parameters, and calls 'git-merge'
17 to merge the retrieved head(s) into the current branch.
18 -With `--rebase`, calls `git-rebase` instead of `git-merge`.
18 +With `--rebase`, calls 'git-rebase' instead of 'git-merge'.
19
20 Note that you can use `.` (current directory) as the
21 <repository> to pull from the local repository -- this is useful
22 when merging local branches into the current branch.
23
24 -Also note that options meant for `git-pull` itself and underlying
25 -`git-merge` must be given before the options meant for `git-fetch`.
24 +Also note that options meant for 'git-pull' itself and underlying
25 +'git-merge' must be given before the options meant for 'git-fetch'.
26
27 OPTIONS
28 -------
@@ -182,7 +182,7 @@ The final command then merges the newly fetched `tmp` into master.
182
183
184 If you tried a pull which resulted in a complex conflicts and
185 -would want to start over, you can recover with `git-reset`.
185 +would want to start over, you can recover with 'git-reset'.
186
187
188 SEE ALSO
Documentation/git-push.txt
+2 -2
@@ -85,7 +85,7 @@ nor in any Push line of the corresponding remotes file---see below).
85 line.
86
87 --receive-pack=<git-receive-pack>::
88 - Path to the `git-receive-pack` program on the remote
88 + Path to the 'git-receive-pack' program on the remote
89 end. Sometimes useful when pushing to a remote
90 repository over ssh, and you do not have the program in
91 a directory on the default $PATH.
@@ -106,7 +106,7 @@ nor in any Push line of the corresponding remotes file---see below).
106
107 --thin::
108 --no-thin::
109 - These options are passed to `git-send-pack`. Thin
109 + These options are passed to 'git-send-pack'. Thin
110 transfer spends extra cycles to minimize the number of
111 objects to be sent and meant to be used on slower connection.
112
Documentation/git-read-tree.txt
+21 -21
@@ -22,8 +22,8 @@ fast-forward (i.e. 2-way) merge, or a 3-way merge, with the `-m`
22 flag. When used with `-m`, the `-u` flag causes it to also update
23 the files in the work tree with the result of the merge.
24
25 -Trivial merges are done by `git-read-tree` itself. Only conflicting paths
26 -will be in unmerged state when `git-read-tree` returns.
25 +Trivial merges are done by 'git-read-tree' itself. Only conflicting paths
26 +will be in unmerged state when 'git-read-tree' returns.
27
28 OPTIONS
29 -------
@@ -54,13 +54,13 @@ OPTIONS
54 Show the progress of checking files out.
55
56 --trivial::
57 - Restrict three-way merge by `git-read-tree` to happen
57 + Restrict three-way merge by 'git-read-tree' to happen
58 only if there is no file-level merging required, instead
59 of resolving merge for trivial cases and leaving
60 conflicting files unresolved in the index.
61
62 --aggressive::
63 - Usually a three-way merge by `git-read-tree` resolves
63 + Usually a three-way merge by 'git-read-tree' resolves
64 the merge for really trivial cases and leaves other
65 cases unresolved in the index, so that Porcelains can
66 implement different merge policies. This flag makes the
@@ -113,7 +113,7 @@ OPTIONS
113
114 Merging
115 -------
116 -If `-m` is specified, `git-read-tree` can perform 3 kinds of
116 +If `-m` is specified, 'git-read-tree' can perform 3 kinds of
117 merge, a single tree merge if only 1 tree is given, a
118 fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
119 provided.
@@ -121,18 +121,18 @@ provided.
121
122 Single Tree Merge
123 ~~~~~~~~~~~~~~~~~
124 -If only 1 tree is specified, `git-read-tree` operates as if the user did not
124 +If only 1 tree is specified, 'git-read-tree' operates as if the user did not
125 specify `-m`, except that if the original index has an entry for a
126 given pathname, and the contents of the path matches with the tree
127 being read, the stat info from the index is used. (In other words, the
128 index's stat()s take precedence over the merged tree's).
129
130 That means that if you do a `git read-tree -m <newtree>` followed by a
131 -`git checkout-index -f -u -a`, the `git-checkout-index` only checks out
131 +`git checkout-index -f -u -a`, the 'git-checkout-index' only checks out
132 the stuff that really changed.
133
134 -This is used to avoid unnecessary false hits when `git-diff-files` is
135 -run after `git-read-tree`.
134 +This is used to avoid unnecessary false hits when 'git-diff-files' is
135 +run after 'git-read-tree'.
136
137
138 Two Tree Merge
@@ -143,7 +143,7 @@ is the head commit of the current repository, and $M is the head
143 of a foreign tree, which is simply ahead of $H (i.e. we are in a
144 fast forward situation).
145
146 -When two trees are specified, the user is telling `git-read-tree`
146 +When two trees are specified, the user is telling 'git-read-tree'
147 the following:
148
149 1. The current index and work tree is derived from $H, but
@@ -193,10 +193,10 @@ Here are the "carry forward" rules:
193
194 In all "keep index" cases, the index entry stays as in the
195 original index file. If the entry were not up to date,
196 -`git-read-tree` keeps the copy in the work tree intact when
196 +'git-read-tree' keeps the copy in the work tree intact when
197 operating under the -u flag.
198
199 -When this form of `git-read-tree` returns successfully, you can
199 +When this form of 'git-read-tree' returns successfully, you can
200 see what "local changes" you made are carried forward by running
201 `git diff-index --cached $M`. Note that this does not
202 necessarily match `git diff-index --cached $H` would have
@@ -213,7 +213,7 @@ output after two-tree merge.
213 Each "index" entry has two bits worth of "stage" state. stage 0 is the
214 normal one, and is the only one you'd see in any kind of normal use.
215
216 -However, when you do `git-read-tree` with three trees, the "stage"
216 +However, when you do 'git-read-tree' with three trees, the "stage"
217 starts out at 1.
218
219 This means that you can do
@@ -229,7 +229,7 @@ branch into the current branch, we use the common ancestor tree
229 as <tree1>, the current branch head as <tree2>, and the other
230 branch head as <tree3>.
231
232 -Furthermore, `git-read-tree` has special-case logic that says: if you see
232 +Furthermore, 'git-read-tree' has special-case logic that says: if you see
233 a file that matches in all respects in the following states, it
234 "collapses" back to "stage0":
235
@@ -245,7 +245,7 @@ a file that matches in all respects in the following states, it
245 - stage 1 and stage 3 are the same and stage 2 is different take
246 stage 2 (we did something while they did nothing)
247
248 -The `git-write-tree` command refuses to write a nonsensical tree, and it
248 +The 'git-write-tree' command refuses to write a nonsensical tree, and it
249 will complain about unmerged entries if it sees a single entry that is not
250 stage 0.
251
@@ -261,7 +261,7 @@ start a 3-way merge with an index file that is already
261 populated. Here is an outline of how the algorithm works:
262
263 - if a file exists in identical format in all three trees, it will
264 - automatically collapse to "merged" state by `git-read-tree`.
264 + automatically collapse to "merged" state by 'git-read-tree'.
265
266 - a file that has _any_ difference what-so-ever in the three trees
267 will stay as separate entries in the index. It's up to "porcelain
@@ -285,8 +285,8 @@ populated. Here is an outline of how the algorithm works:
285 matching "stage1" entry if it exists too. .. all the normal
286 trivial rules ..
287
288 -You would normally use `git-merge-index` with supplied
289 -`git-merge-one-file` to do this last step. The script updates
288 +You would normally use 'git-merge-index' with supplied
289 +'git-merge-one-file' to do this last step. The script updates
290 the files in the working tree as it merges each path and at the
291 end of a successful merge.
292
@@ -308,7 +308,7 @@ $ JC=`git rev-parse --verify "HEAD^0"`
308 $ git checkout-index -f -u -a $JC
309 ----------------
310
311 -You do random edits, without running `git-update-index`. And then
311 +You do random edits, without running 'git-update-index'. And then
312 you notice that the tip of your "upstream" tree has advanced
313 since you pulled from him:
314
@@ -334,14 +334,14 @@ your work-in-progress changes, and your work tree would be
334 updated to the result of the merge.
335
336 However, if you have local changes in the working tree that
337 -would be overwritten by this merge, `git-read-tree` will refuse
337 +would be overwritten by this merge, 'git-read-tree' will refuse
338 to run to prevent your changes from being lost.
339
340 In other words, there is no need to worry about what exists only
341 in the working tree. When you have local changes in a part of
342 the project that is not involved in the merge, your changes do
343 not interfere with the merge, and are kept intact. When they
344 -*do* interfere, the merge does not even start (`git-read-tree`
344 +*do* interfere, the merge does not even start ('git-read-tree'
345 complains loudly and fails without modifying anything). In such
346 a case, you can simply continue doing what you were in the
347 middle of doing, and when your working tree is ready (i.e. you
Documentation/git-rebase.txt
+13 -13
@@ -16,7 +16,7 @@ SYNOPSIS
16
17 DESCRIPTION
18 -----------
19 -If <branch> is specified, `git-rebase` will perform an automatic
19 +If <branch> is specified, 'git-rebase' will perform an automatic
20 `git checkout <branch>` before doing anything else. Otherwise
21 it remains on the current branch.
22
@@ -167,8 +167,8 @@ This is useful if F and G were flawed in some way, or should not be
167 part of topicA. Note that the argument to --onto and the <upstream>
168 parameter can be any valid commit-ish.
169
170 -In case of conflict, `git-rebase` will stop at the first problematic commit
171 -and leave conflict markers in the tree. You can use `git-diff` to locate
170 +In case of conflict, 'git-rebase' will stop at the first problematic commit
171 +and leave conflict markers in the tree. You can use 'git-diff' to locate
172 the markers (<<<<<<) and make edits to resolve the conflict. For each
173 file you edit, you need to tell git that the conflict has been resolved,
174 typically this would be done with
@@ -184,7 +184,7 @@ desired resolution, you can continue the rebasing process with
184 git rebase --continue
185
186
187 -Alternatively, you can undo the `git-rebase` with
187 +Alternatively, you can undo the 'git-rebase' with
188
189
190 git rebase --abort
@@ -224,8 +224,8 @@ OPTIONS
224 Use the given merge strategy; can be supplied more than
225 once to specify them in the order they should be tried.
226 If there is no `-s` option, a built-in list of strategies
227 - is used instead (`git-merge-recursive` when merging a single
228 - head, `git-merge-octopus` otherwise). This implies --merge.
227 + is used instead ('git-merge-recursive' when merging a single
228 + head, 'git-merge-octopus' otherwise). This implies --merge.
229
230 -v::
231 --verbose::
@@ -238,7 +238,7 @@ OPTIONS
238 ever ignored.
239
240 --whitespace=<nowarn|warn|error|error-all|strip>::
241 - This flag is passed to the `git-apply` program
241 + This flag is passed to the 'git-apply' program
242 (see linkgit:git-apply[1]) that applies the patch.
243
244 -i::
@@ -314,12 +314,12 @@ pick fa1afe1 The oneline of the next commit
314 ...
315 -------------------------------------------
316
317 -The oneline descriptions are purely for your pleasure; `git-rebase` will
317 +The oneline descriptions are purely for your pleasure; 'git-rebase' will
318 not look at them but at the commit names ("deadbee" and "fa1afe1" in this
319 example), so do not delete or edit the names.
320
321 By replacing the command "pick" with the command "edit", you can tell
322 -`git-rebase` to stop after applying that commit, so that you can edit
322 +'git-rebase' to stop after applying that commit, so that you can edit
323 the files and/or the commit message, amend the commit, and continue
324 rebasing.
325
@@ -334,7 +334,7 @@ the loop with `git rebase --continue`.
334
335 For example, if you want to reorder the last 5 commits, such that what
336 was HEAD~4 becomes the new HEAD. To achieve that, you would call
337 -`git-rebase` like this:
337 +'git-rebase' like this:
338
339 ----------------------
340 $ git rebase -i HEAD~5
@@ -364,7 +364,7 @@ SPLITTING COMMITS
364 -----------------
365
366 In interactive mode, you can mark commits with the action "edit". However,
367 -this does not necessarily mean that `git-rebase` expects the result of this
367 +this does not necessarily mean that 'git-rebase' expects the result of this
368 edit to be exactly one commit. Indeed, you can undo the commit, or you can
369 add other commits. This can be used to split a commit into two:
370
@@ -380,7 +380,7 @@ add other commits. This can be used to split a commit into two:
380
381 - Now add the changes to the index that you want to have in the first
382 commit. You can use `git add` (possibly interactively) or
383 - `git-gui` (or both) to do that.
383 + 'git-gui' (or both) to do that.
384
385 - Commit the now-current index with whatever commit message is appropriate
386 now.
@@ -391,7 +391,7 @@ add other commits. This can be used to split a commit into two:
391
392 If you are not absolutely sure that the intermediate revisions are
393 consistent (they compile, pass the testsuite, etc.) you should use
394 -`git-stash` to stash away the not-yet-committed changes
394 +'git-stash' to stash away the not-yet-committed changes
395 after each commit, test, and amend the commit if fixes are necessary.
396
397
Documentation/git-receive-pack.txt
+6 -6
@@ -12,23 +12,23 @@ SYNOPSIS
12
13 DESCRIPTION
14 -----------
15 -Invoked by `git-send-pack` and updates the repository with the
15 +Invoked by 'git-send-pack' and updates the repository with the
16 information fed from the remote end.
17
18 This command is usually not invoked directly by the end user.
19 -The UI for the protocol is on the `git-send-pack` side, and the
19 +The UI for the protocol is on the 'git-send-pack' side, and the
20 program pair is meant to be used to push updates to remote
21 repository. For pull operations, see linkgit:git-fetch-pack[1].
22
23 The command allows for creation and fast forwarding of sha1 refs
24 (heads/tags) on the remote end (strictly speaking, it is the
25 -local end `git-receive-pack` runs, but to the user who is sitting at
25 +local end 'git-receive-pack' runs, but to the user who is sitting at
26 the send-pack end, it is updating the remote. Confused?)
27
28 There are other real-world examples of using update and
29 post-update hooks found in the Documentation/howto directory.
30
31 -`git-receive-pack` honours the receive.denyNonFastForwards config
31 +'git-receive-pack' honours the receive.denyNonFastForwards config
32 option, which tells it if updates to a ref should be denied if they
33 are not fast-forwards.
34
@@ -125,7 +125,7 @@ non-zero exit code will generate an error message.
125
126 Note that it is possible for refname to not have sha1-new when this
127 hook runs. This can easily occur if another user modifies the ref
128 -after it was updated by `git-receive-pack`, but before the hook was able
128 +after it was updated by 'git-receive-pack', but before the hook was able
129 to evaluate it. It is recommended that hooks rely on sha1-new
130 rather than the current value of refname.
131
@@ -137,7 +137,7 @@ post-update will called with the list of refs that have been updated.
137 This can be used to implement any repository wide cleanup tasks.
138
139 The exit code from this hook invocation is ignored; the only thing
140 -left for `git-receive-pack` to do at that point is to exit itself
140 +left for 'git-receive-pack' to do at that point is to exit itself
141 anyway.
142
143 This hook can be used, for example, to run `git update-server-info`
Documentation/git-repack.txt
+7 -7
@@ -47,29 +47,29 @@ OPTIONS
47 deleted by way of being left in the old pack and then
48 removed. Instead, the loose unreachable objects
49 will be pruned according to normal expiry rules
50 - with the next `git-gc` invocation. See linkgit:git-gc[1].
50 + with the next 'git-gc' invocation. See linkgit:git-gc[1].
51
52 -d::
53 After packing, if the newly created packs make some
54 existing packs redundant, remove the redundant packs.
55 - Also run `git-prune-packed` to remove redundant
55 + Also run 'git-prune-packed' to remove redundant
56 loose object files.
57
58 -l::
59 - Pass the `--local` option to `git-pack-objects`. See
59 + Pass the `--local` option to 'git-pack-objects'. See
60 linkgit:git-pack-objects[1].
61
62 -f::
63 - Pass the `--no-reuse-delta` option to `git-pack-objects`. See
63 + Pass the `--no-reuse-delta` option to 'git-pack-objects'. See
64 linkgit:git-pack-objects[1].
65
66 -q::
67 - Pass the `-q` option to `git-pack-objects`. See
67 + Pass the `-q` option to 'git-pack-objects'. See
68 linkgit:git-pack-objects[1].
69
70 -n::
71 Do not update the server information with
72 - `git-update-server-info`. This option skips
72 + 'git-update-server-info'. This option skips
73 updating local catalog files needed to publish
74 this repository (or a direct copy of it)
75 over HTTP or FTP. See linkgit:git-update-server-info[1].
@@ -107,7 +107,7 @@ Configuration
107
108 When configuration variable `repack.UseDeltaBaseOffset` is set
109 for the repository, the command passes `--delta-base-offset`
110 -option to `git-pack-objects`; this typically results in slightly
110 +option to 'git-pack-objects'; this typically results in slightly
111 smaller packs, but the generated packs are incompatible with
112 versions of git older than (and including) v1.4.3; do not set
113 the variable in a repository that older version of git needs to
Documentation/git-rerere.txt
+14 -14
@@ -30,14 +30,14 @@ enable this command.
30 COMMANDS
31 --------
32
33 -Normally, `git-rerere` is run without arguments or user-intervention.
33 +Normally, 'git-rerere' is run without arguments or user-intervention.
34 However, it has several commands that allow it to interact with
35 its working state.
36
37 'clear'::
38
39 This resets the metadata used by rerere if a merge resolution is to be
40 -is aborted. Calling `git-am --skip` or `git-rebase [--skip|--abort]`
40 +is aborted. Calling 'git-am --skip' or 'git-rebase [--skip|--abort]'
41 will automatically invoke this command.
42
43 'diff'::
@@ -142,33 +142,33 @@ finally ready and merged into the master branch. This merge
142 would require you to resolve the conflict, introduced by the
143 commits marked with `*`. However, often this conflict is the
144 same conflict you resolved when you created the test merge you
145 -blew away. `git-rerere` command helps you to resolve this final
145 +blew away. 'git-rerere' command helps you to resolve this final
146 conflicted merge using the information from your earlier hand
147 resolve.
148
149 -Running the `git-rerere` command immediately after a conflicted
149 +Running the 'git-rerere' command immediately after a conflicted
150 automerge records the conflicted working tree files, with the
151 usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in
152 them. Later, after you are done resolving the conflicts,
153 -running `git-rerere` again records the resolved state of these
153 +running 'git-rerere' again records the resolved state of these
154 files. Suppose you did this when you created the test merge of
155 master into the topic branch.
156
157 -Next time, running `git-rerere` after seeing a conflicted
157 +Next time, running 'git-rerere' after seeing a conflicted
158 automerge, if the conflict is the same as the earlier one
159 recorded, it is noticed and a three-way merge between the
160 earlier conflicted automerge, the earlier manual resolution, and
161 the current conflicted automerge is performed by the command.
162 If this three-way merge resolves cleanly, the result is written
163 out to your working tree file, so you would not have to manually
164 -resolve it. Note that `git-rerere` leaves the index file alone,
164 +resolve it. Note that 'git-rerere' leaves the index file alone,
165 so you still need to do the final sanity checks with `git diff`
166 -(or `git diff -c`) and `git-add` when you are satisfied.
166 +(or `git diff -c`) and 'git-add' when you are satisfied.
167
168 -As a convenience measure, `git-merge` automatically invokes
169 -`git-rerere` when it exits with a failed automerge, which
168 +As a convenience measure, 'git-merge' automatically invokes
169 +'git-rerere' when it exits with a failed automerge, which
170 records it if it is a new conflict, or reuses the earlier hand
171 -resolve when it is not. `git-commit` also invokes `git-rerere`
171 +resolve when it is not. 'git-commit' also invokes 'git-rerere'
172 when recording a merge result. What this means is that you do
173 not have to do anything special yourself (Note: you still have
174 to set the config variable rerere.enabled to enable this command).
@@ -178,8 +178,8 @@ resolution is recorded, and it will be reused when you do the
178 actual merge later with updated master and topic branch, as long
179 as the earlier resolution is still applicable.
180
181 -The information `git-rerere` records is also used when running
182 -`git-rebase`. After blowing away the test merge and continuing
181 +The information 'git-rerere' records is also used when running
182 +'git-rebase'. After blowing away the test merge and continuing
183 development on the topic branch:
184
185 ------------
@@ -198,7 +198,7 @@ you could run `git rebase master topic`, to keep yourself
198 up-to-date even before your topic is ready to be sent upstream.
199 This would result in falling back to three-way merge, and it
200 would conflict the same way the test merge you resolved earlier.
201 -`git-rerere` is run by `git-rebase` to help you resolve this
201 +'git-rerere' is run by 'git-rebase' to help you resolve this
202 conflict.
203
204
Documentation/git-reset.txt
+1 -1
@@ -37,7 +37,7 @@ OPTIONS
37 --soft::
38 Does not touch the index file nor the working tree at all, but
39 requires them to be in a good order. This leaves all your changed
40 - files "Changes to be committed", as `git-status` would
40 + files "Changes to be committed", as 'git-status' would
41 put it.
42
43 --hard::
Documentation/git-rev-list.txt
+3 -3
@@ -83,11 +83,11 @@ between the two operands. The following two commands are equivalent:
83 $ git rev-list A...B
84 -----------------------------------------------------------------------
85
86 -`git-rev-list` is a very essential git program, since it
86 +'git-rev-list' is a very essential git program, since it
87 provides the ability to build and traverse commit ancestry graphs. For
88 this reason, it has a lot of different options that enables it to be
89 -used by commands as different as `git-bisect` and
90 -`git-repack`.
89 +used by commands as different as 'git-bisect' and
90 +'git-repack'.
91
92 OPTIONS
93 -------
Documentation/git-rev-parse.txt
+12 -12
@@ -15,16 +15,16 @@ DESCRIPTION
15
16 Many git porcelainish commands take mixture of flags
17 (i.e. parameters that begin with a dash '-') and parameters
18 -meant for the underlying `git-rev-list` command they use internally
18 +meant for the underlying 'git-rev-list' command they use internally
19 and flags and parameters for the other commands they use
20 -downstream of `git-rev-list`. This command is used to
20 +downstream of 'git-rev-list'. This command is used to
21 distinguish between them.
22
23
24 OPTIONS
25 -------
26 --parseopt::
27 - Use `git-rev-parse` in option parsing mode (see PARSEOPT section below).
27 + Use 'git-rev-parse' in option parsing mode (see PARSEOPT section below).
28
29 --keep-dash-dash::
30 Only meaningful in `--parseopt` mode. Tells the option parser to echo
@@ -32,11 +32,11 @@ OPTIONS
32
33 --revs-only::
34 Do not output flags and parameters not meant for
35 - `git-rev-list` command.
35 + 'git-rev-list' command.
36
37 --no-revs::
38 Do not output flags and parameters meant for
39 - `git-rev-list` command.
39 + 'git-rev-list' command.
40
41 --flags::
42 Do not output non-flag parameters.
@@ -64,7 +64,7 @@ OPTIONS
64 properly quoted for consumption by shell. Useful when
65 you expect your parameter to contain whitespaces and
66 newlines (e.g. when using pickaxe `-S` with
67 - `git-diff-\*`).
67 + 'git-diff-\*').
68
69 --not::
70 When showing object names, prefix them with '{caret}' and
@@ -129,12 +129,12 @@ OPTIONS
129 --since=datestring::
130 --after=datestring::
131 Parse the date string, and output the corresponding
132 - --max-age= parameter for `git-rev-list`.
132 + --max-age= parameter for 'git-rev-list'.
133
134 --until=datestring::
135 --before=datestring::
136 Parse the date string, and output the corresponding
137 - --min-age= parameter for `git-rev-list`.
137 + --min-age= parameter for 'git-rev-list'.
138
139 <args>...::
140 Flags and parameters to be parsed.
@@ -155,7 +155,7 @@ blobs contained in a commit.
155 name the same commit object if there are no other object in
156 your repository whose object name starts with dae86e.
157
158 -* An output from `git-describe`; i.e. a closest tag, followed by a
158 +* An output from 'git-describe'; i.e. a closest tag, followed by a
159 dash, a `g`, and an abbreviated object name.
160
161 * A symbolic ref name. E.g. 'master' typically means the commit
@@ -278,7 +278,7 @@ G H I J
278 SPECIFYING RANGES
279 -----------------
280
281 -History traversing commands such as `git-log` operate on a set
281 +History traversing commands such as 'git-log' operate on a set
282 of commits, not just a single commit. To these commands,
283 specifying a single revision with the notation described in the
284 previous section means the set of commits reachable from that
@@ -319,7 +319,7 @@ Here are a handful of examples:
319 PARSEOPT
320 --------
321
322 -In `--parseopt` mode, `git-rev-parse` helps massaging options to bring to shell
322 +In `--parseopt` mode, 'git-rev-parse' helps massaging options to bring to shell
323 scripts the same facilities C builtins have. It works as an option normalizer
324 (e.g. splits single switches aggregate values), a bit like `getopt(1)` does.
325
@@ -331,7 +331,7 @@ usage on the standard error stream, and exits with code 129.
331 Input Format
332 ~~~~~~~~~~~~
333
334 -`git-rev-parse --parseopt` input format is fully text based. It has two parts,
334 +'git-rev-parse --parseopt' input format is fully text based. It has two parts,
335 separated by a line that contains only `--`. The lines before the separator
336 (should be more than one) are used for the usage.
337 The lines after the separator describe the options.
Documentation/git-revert.txt
+2 -2
@@ -24,7 +24,7 @@ OPTIONS
24
25 -e::
26 --edit::
27 - With this option, `git-revert` will let you edit the commit
27 + With this option, 'git-revert' will let you edit the commit
28 message prior to committing the revert. This is the default if
29 you run the command from a terminal.
30
@@ -37,7 +37,7 @@ OPTIONS
37 relative to the specified parent.
38
39 --no-edit::
40 - With this option, `git-revert` will not start the commit
40 + With this option, 'git-revert' will not start the commit
41 message editor.
42
43 -n::
Documentation/git-rm.txt
+2 -2
@@ -12,7 +12,7 @@ SYNOPSIS
12 DESCRIPTION
13 -----------
14 Remove files from the index, or from the working tree and the index.
15 -`git-rm` will not remove a file from just your working directory.
15 +'git-rm' will not remove a file from just your working directory.
16 (There is no option to remove a file only from the work tree
17 and yet keep it in the index; use `/bin/rm` if you want to do that.)
18 The files being removed have to be identical to the tip of the branch,
@@ -63,7 +63,7 @@ OPTIONS
63
64 -q::
65 --quiet::
66 - `git-rm` normally outputs one line (in the form of an "rm" command)
66 + 'git-rm' normally outputs one line (in the form of an "rm" command)
67 for each file removed. This option suppresses that output.
68
69
Documentation/git-send-pack.txt
+5 -5
@@ -12,17 +12,17 @@ SYNOPSIS
12
13 DESCRIPTION
14 -----------
15 -Usually you would want to use `git-push`, which is a
15 +Usually you would want to use 'git-push', which is a
16 higher-level wrapper of this command, instead. See linkgit:git-push[1].
17
18 -Invokes `git-receive-pack` on a possibly remote repository, and
18 +Invokes 'git-receive-pack' on a possibly remote repository, and
19 updates it from the current repository, sending named refs.
20
21
22 OPTIONS
23 -------
24 --receive-pack=<git-receive-pack>::
25 - Path to the `git-receive-pack` program on the remote
25 + Path to the 'git-receive-pack' program on the remote
26 end. Sometimes useful when pushing to a remote
27 repository over ssh, and you do not have the program in
28 a directory on the default $PATH.
@@ -53,7 +53,7 @@ OPTIONS
53
54 <host>::
55 A remote host to house the repository. When this
56 - part is specified, `git-receive-pack` is invoked via
56 + part is specified, 'git-receive-pack' is invoked via
57 ssh.
58
59 <directory>::
@@ -86,7 +86,7 @@ and the destination side (after the colon). The ref to be
86 pushed is determined by finding a match that matches the source
87 side, and where it is pushed is determined by using the
88 destination side. The rules used to match a ref are the same
89 -rules used by `git-rev-parse` to resolve a symbolic ref
89 +rules used by 'git-rev-parse' to resolve a symbolic ref
90 name. See linkgit:git-rev-parse[1].
91
92 - It is an error if <src> does not match exactly one of the
Documentation/git-sh-setup.txt
+1 -1
@@ -16,7 +16,7 @@ This is not a command the end user would want to run. Ever.
16 This documentation is meant for people who are studying the
17 Porcelain-ish scripts and/or are writing new ones.
18
19 -The `git-sh-setup` scriptlet is designed to be sourced (using
19 +The 'git-sh-setup' scriptlet is designed to be sourced (using
20 `.`) by other shell scripts to set up some variables pointing at
21 the normal git directories and a few helper shell functions.
22
Documentation/git-shell.txt
+1 -1
@@ -18,7 +18,7 @@ of server-side GIT commands implementing the pull/push functionality.
18 The commands can be executed only by the '-c' option; the shell is not
19 interactive.
20
21 -Currently, only the `git-receive-pack` and `git-upload-pack` commands
21 +Currently, only the 'git-receive-pack' and 'git-upload-pack' commands
22 are permitted to be called, with a single required argument.
23
24 Author
Documentation/git-shortlog.txt
+1 -1
@@ -13,7 +13,7 @@ git shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[
13
14 DESCRIPTION
15 -----------
16 -Summarizes `git-log` output in a format suitable for inclusion
16 +Summarizes 'git-log' output in a format suitable for inclusion
17 in release announcements. Each commit will be grouped by author and
18 the first line of the commit message will be shown.
19
Documentation/git-show-branch.txt
+1 -1
@@ -75,7 +75,7 @@ OPTIONS
75
76 --merge-base::
77 Instead of showing the commit list, just act like the
78 - `git-merge-base -a` command, except that it can accept
78 + 'git-merge-base -a' command, except that it can accept
79 more than two heads.
80
81 --independent::
Documentation/git-show-index.txt
+2 -2
@@ -14,10 +14,10 @@ SYNOPSIS
14 DESCRIPTION
15 -----------
16 Reads given idx file for packed git archive created with
17 -`git-pack-objects` command, and dumps its contents.
17 +'git-pack-objects' command, and dumps its contents.
18
19 The information it outputs is subset of what you can get from
20 -`git-verify-pack -v`; this command only shows the packfile
20 +'git-verify-pack -v'; this command only shows the packfile
21 offset and SHA1 of each object.
22
23
Documentation/git-show-ref.txt
+2 -2
@@ -74,7 +74,7 @@ OPTIONS
74 --exclude-existing::
75 --exclude-existing=pattern::
76
77 - Make `git-show-ref` act as a filter that reads refs from stdin of the
77 + Make 'git-show-ref' act as a filter that reads refs from stdin of the
78 form "^(?:<anything>\s)?<refname>(?:\^\{\})?$" and performs the
79 following actions on each:
80 (1) strip "^{}" at the end of line if any;
@@ -137,7 +137,7 @@ When using the '--verify' flag, the command requires an exact path:
137
138 will only match the exact branch called "master".
139
140 -If nothing matches, `git-show-ref` will return an error code of 1,
140 +If nothing matches, 'git-show-ref' will return an error code of 1,
141 and in the case of verification, it will show an error message.
142
143 For scripting, you can ask it to be quiet with the "--quiet" flag, which
Documentation/git-show.txt
+3 -3
@@ -16,16 +16,16 @@ Shows one or more objects (blobs, trees, tags and commits).
16
17 For commits it shows the log message and textual diff. It also
18 presents the merge commit in a special format as produced by
19 -`git-diff-tree --cc`.
19 +'git-diff-tree --cc'.
20
21 For tags, it shows the tag message and the referenced objects.
22
23 -For trees, it shows the names (equivalent to `git-ls-tree`
23 +For trees, it shows the names (equivalent to 'git-ls-tree'
24 with \--name-only).
25
26 For plain blobs, it shows the plain contents.
27
28 -The command takes options applicable to the `git-diff-tree` command to
28 +The command takes options applicable to the 'git-diff-tree' command to
29 control how the changes the commit introduces are shown.
30
31 This manual page describes only the most frequently used options.
Documentation/git-stash.txt
+3 -3
@@ -56,7 +56,7 @@ stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
56 stash@{1}: On master: 9cc0589... Add git-stash
57 ----------------------------------------------------------------
58 +
59 -The command takes options applicable to the `git-log`
59 +The command takes options applicable to the 'git-log'
60 command to control what is shown and how. See linkgit:git-log[1].
61
62 show [<stash>]::
@@ -64,7 +64,7 @@ show [<stash>]::
64 Show the changes recorded in the stash as a diff between the
65 stashed state and its original parent. When no `<stash>` is given,
66 shows the latest one. By default, the command shows the diffstat, but
67 - it will accept any format known to `git-diff` (e.g., `git stash show
67 + it will accept any format known to 'git-diff' (e.g., `git stash show
68 -p stash@\{1}` to view the second most recent stash in patch form).
69
70 apply [--index] [<stash>]::
@@ -158,7 +158,7 @@ $ git reset --soft HEAD^
158 ... continue hacking ...
159 ----------------------------------------------------------------
160 +
161 -You can use `git-stash` to simplify the above, like this:
161 +You can use 'git-stash' to simplify the above, like this:
162 +
163 ----------------------------------------------------------------
164 ... hack hack hack ...
Documentation/git-status.txt
+3 -3
@@ -17,12 +17,12 @@ current HEAD commit, paths that have differences between the working
17 tree and the index file, and paths in the working tree that are not
18 tracked by git (and are not ignored by linkgit:gitignore[5]). The first
19 are what you _would_ commit by running `git commit`; the second and
20 -third are what you _could_ commit by running `git-add` before running
20 +third are what you _could_ commit by running 'git-add' before running
21 `git commit`.
22
23 -The command takes the same set of options as `git-commit`; it
23 +The command takes the same set of options as 'git-commit'; it
24 shows what would be committed if the same options are given to
25 -`git-commit`.
25 +'git-commit'.
26
27 If there is no path that is different between the index file and
28 the current HEAD commit (i.e., there is nothing to commit by running
Documentation/git-submodule.txt
+2 -2
@@ -32,11 +32,11 @@ add::
32 status::
33 Show the status of the submodules. This will print the SHA-1 of the
34 currently checked out commit for each submodule, along with the
35 - submodule path and the output of `git-describe` for the
35 + submodule path and the output of 'git-describe' for the
36 SHA-1. Each SHA-1 will be prefixed with `-` if the submodule is not
37 initialized and `+` if the currently checked out submodule commit
38 does not match the SHA-1 found in the index of the containing
39 - repository. This command is the default command for `git-submodule`.
39 + repository. This command is the default command for 'git-submodule'.
40
41 init::
42 Initialize the submodules, i.e. register in .git/config each submodule
Documentation/git-svn.txt
+53 -53
@@ -11,17 +11,17 @@ SYNOPSIS
11
12 DESCRIPTION
13 -----------
14 -`git-svn` is a simple conduit for changesets between Subversion and git.
14 +'git-svn' is a simple conduit for changesets between Subversion and git.
15 It is not to be confused with linkgit:git-svnimport[1], which is
16 read-only.
17
18 -`git-svn` was originally designed for an individual developer who wants a
18 +'git-svn' was originally designed for an individual developer who wants a
19 bidirectional flow of changesets between a single branch in Subversion
20 and an arbitrary number of branches in git. Since its inception,
21 -`git-svn` has gained the ability to track multiple branches in a manner
22 -similar to `git-svnimport`.
21 +'git-svn' has gained the ability to track multiple branches in a manner
22 +similar to 'git-svnimport'.
23
24 -`git-svn` is especially useful when it comes to tracking repositories
24 +'git-svn' is especially useful when it comes to tracking repositories
25 not organized in the way Subversion developers recommend (trunk,
26 branches, tags directories).
27
@@ -31,7 +31,7 @@ COMMANDS
31
32 'init'::
33 Initializes an empty git repository with additional
34 - metadata directories for `git-svn`. The Subversion URL
34 + metadata directories for 'git-svn'. The Subversion URL
35 may be specified as a command-line argument, or as full
36 URL arguments to -T/-t/-b. Optionally, the target
37 directory to operate on can be specified as a second
@@ -107,20 +107,20 @@ COMMANDS
107 This fetches revisions from the SVN parent of the current HEAD
108 and rebases the current (uncommitted to SVN) work against it.
109
110 -This works similarly to `svn update` or `git-pull` except that
111 -it preserves linear history with `git-rebase` instead of
112 -`git-merge` for ease of dcommiting with `git-svn`.
110 +This works similarly to `svn update` or 'git-pull' except that
111 +it preserves linear history with 'git-rebase' instead of
112 +'git-merge' for ease of dcommiting with 'git-svn'.
113
114 -This accepts all options that `git-svn fetch` and `git-rebase`
114 +This accepts all options that 'git-svn fetch' and 'git-rebase'
115 accept. However, '--fetch-all' only fetches from the current
116 [svn-remote], and not all [svn-remote] definitions.
117
118 -Like `git-rebase`; this requires that the working tree be clean
118 +Like 'git-rebase'; this requires that the working tree be clean
119 and have no uncommitted changes.
120
121 -l;;
122 --local;;
123 - Do not fetch remotely; only run `git-rebase` against the
123 + Do not fetch remotely; only run 'git-rebase' against the
124 last fetched commit from the upstream SVN.
125
126 'dcommit'::
@@ -128,7 +128,7 @@ and have no uncommitted changes.
128 repository, and then rebase or reset (depending on whether or
129 not there is a diff between SVN and head). This will create
130 a revision in SVN for each commit in git.
131 - It is recommended that you run `git-svn` fetch and rebase (not
131 + It is recommended that you run 'git-svn' fetch and rebase (not
132 pull or merge) your commits against the latest changes in the
133 SVN repository.
134 An optional command-line argument may be specified as an
@@ -173,7 +173,7 @@ NOTE: SVN itself only stores times in UTC and nothing else. The regular svn
173 client converts the UTC time to the local time (or based on the TZ=
174 environment). This command has the same behaviour.
175 +
176 -Any other arguments are passed directly to `git-log`
176 +Any other arguments are passed directly to 'git-log'
177
178 'blame'::
179 Show what revision and author last modified each line of a file. The
@@ -181,10 +181,10 @@ Any other arguments are passed directly to `git-log`
181 `svn blame' by default. Like the SVN blame command,
182 local uncommitted changes in the working copy are ignored;
183 the version of the file in the HEAD revision is annotated. Unknown
184 - arguments are passed directly to `git-blame`.
184 + arguments are passed directly to 'git-blame'.
185 +
186 --git-format;;
187 - Produce output in the same format as `git-blame`, but with
187 + Produce output in the same format as 'git-blame', but with
188 SVN revision numbers instead of git commit hashes. In this mode,
189 changes that haven't been committed to SVN (including local
190 working-copy edits) are shown as revision 0.
@@ -203,7 +203,7 @@ Any other arguments are passed directly to `git-log`
203 absolutely no attempts to do patching when committing to SVN, it
204 simply overwrites files with those specified in the tree or
205 commit. All merging is assumed to have taken place
206 - independently of `git-svn` functions.
206 + independently of 'git-svn' functions.
207
208 'create-ignore'::
209 Recursively finds the svn:ignore property on directories and
@@ -219,12 +219,12 @@ Any other arguments are passed directly to `git-log`
219 'commit-diff'::
220 Commits the diff of two tree-ish arguments from the
221 command-line. This command is intended for interoperability with
222 - `git-svnimport` and does not rely on being inside an `git-svn
222 + 'git-svnimport' and does not rely on being inside an `git-svn
223 init`-ed repository. This command takes three arguments, (a) the
224 original tree to diff against, (b) the new tree result, (c) the
225 URL of the target Subversion repository. The final argument
226 - (URL) may be omitted if you are working from a `git-svn`-aware
227 - repository (that has been `init`-ed with `git-svn`).
226 + (URL) may be omitted if you are working from a 'git-svn'-aware
227 + repository (that has been `init`-ed with 'git-svn').
228 The -r<revision> option is required for this.
229
230 'info'::
@@ -255,7 +255,7 @@ OPTIONS
255 --shared[={false|true|umask|group|all|world|everybody}]::
256 --template=<template_directory>::
257 Only used with the 'init' command.
258 - These are passed directly to `git-init`.
258 + These are passed directly to 'git-init'.
259
260 -r <ARG>::
261 --revision <ARG>::
@@ -277,7 +277,7 @@ Only used with the 'set-tree' command.
277
278 Read a list of commits from stdin and commit them in reverse
279 order. Only the leading sha1 is read from each line, so
280 -`git-rev-list --pretty=oneline` output can be used.
280 +'git-rev-list --pretty=oneline' output can be used.
281
282 --rmdir::
283
@@ -307,7 +307,7 @@ config key: svn.edit
307
308 Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
309
310 -They are both passed directly to `git-diff-tree`; see
310 +They are both passed directly to 'git-diff-tree'; see
311 linkgit:git-diff-tree[1] for more information.
312
313 [verse]
@@ -317,24 +317,24 @@ config key: svn.findcopiesharder
317 -A<filename>::
318 --authors-file=<filename>::
319
320 -Syntax is compatible with the files used by `git-svnimport` and
321 -`git-cvsimport`:
320 +Syntax is compatible with the files used by 'git-svnimport' and
321 +'git-cvsimport':
322
323 ------------------------------------------------------------------------
324 loginname = Joe User <user@example.com>
325 ------------------------------------------------------------------------
326
327 -If this option is specified and `git-svn` encounters an SVN
328 -committer name that does not exist in the authors-file, `git-svn`
327 +If this option is specified and 'git-svn' encounters an SVN
328 +committer name that does not exist in the authors-file, 'git-svn'
329 will abort operation. The user will then have to add the
330 -appropriate entry. Re-running the previous `git-svn` command
330 +appropriate entry. Re-running the previous 'git-svn' command
331 after the authors-file is modified should continue operation.
332
333 config key: svn.authorsfile
334
335 -q::
336 --quiet::
337 - Make `git-svn` less verbose.
337 + Make 'git-svn' less verbose.
338
339 --repack[=<n>]::
340 --repack-flags=<flags>::
@@ -346,7 +346,7 @@ with many revisions.
346 to fetch before repacking. This defaults to repacking every
347 1000 commits fetched if no argument is specified.
348
349 ---repack-flags are passed directly to `git-repack`.
349 +--repack-flags are passed directly to 'git-repack'.
350
351 [verse]
352 config key: svn.repack
@@ -359,8 +359,8 @@ config key: svn.repackflags
359
360 These are only used with the 'dcommit' and 'rebase' commands.
361
362 -Passed directly to `git-rebase` when using 'dcommit' if a
363 -`git-reset` cannot be used (see 'dcommit').
362 +Passed directly to 'git-rebase' when using 'dcommit' if a
363 +'git-reset' cannot be used (see 'dcommit').
364
365 -n::
366 --dry-run::
@@ -413,18 +413,18 @@ svn-remote.<name>.noMetadata::
413
414 This gets rid of the 'git-svn-id:' lines at the end of every commit.
415
416 -If you lose your .git/svn/git-svn/.rev_db file, `git-svn` will not
416 +If you lose your .git/svn/git-svn/.rev_db file, 'git-svn' will not
417 be able to rebuild it and you won't be able to fetch again,
418 either. This is fine for one-shot imports.
419
420 -The `git-svn log` command will not work on repositories using
420 +The 'git-svn log' command will not work on repositories using
421 this, either. Using this conflicts with the 'useSvmProps'
422 option for (hopefully) obvious reasons.
423
424 svn.useSvmProps::
425 svn-remote.<name>.useSvmProps::
426
427 -This allows `git-svn` to re-map repository URLs and UUIDs from
427 +This allows 'git-svn' to re-map repository URLs and UUIDs from
428 mirrors created using SVN::Mirror (or svk) for metadata.
429
430 If an SVN revision has a property, "svm:headrev", it is likely
@@ -443,7 +443,7 @@ svn-remote.<name>.useSvnsyncprops::
443
444 svn-remote.<name>.rewriteRoot::
445 This allows users to create repositories from alternate
446 - URLs. For example, an administrator could run `git-svn` on the
446 + URLs. For example, an administrator could run 'git-svn' on the
447 server locally (accessing via file://) but wish to distribute
448 the repository with a public http:// or svn:// URL in the
449 metadata so users of it will see the public URL.
@@ -451,7 +451,7 @@ svn-remote.<name>.rewriteRoot::
451 --
452
453 Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
454 -options all affect the metadata generated and used by `git-svn`; they
454 +options all affect the metadata generated and used by 'git-svn'; they
455 *must* be set in the configuration file before any history is imported
456 and these settings should never be changed once they are set.
457
@@ -498,12 +498,12 @@ Tracking and contributing to an entire Subversion-managed project
498 # of dcommit/rebase/show-ignore should be the same as above.
499 ------------------------------------------------------------------------
500
501 -The initial `git-svn clone` can be quite time-consuming
501 +The initial 'git-svn clone' can be quite time-consuming
502 (especially for large Subversion repositories). If multiple
503 people (or one person with multiple machines) want to use
504 -`git-svn` to interact with the same Subversion repository, you can
505 -do the initial `git-svn clone` to a repository on a server and
506 -have each person clone that repository with `git-clone`:
504 +'git-svn' to interact with the same Subversion repository, you can
505 +do the initial 'git-svn clone' to a repository on a server and
506 +have each person clone that repository with 'git-clone':
507
508 ------------------------------------------------------------------------
509 # Do the initial import on a server
@@ -524,7 +524,7 @@ have each person clone that repository with `git-clone`:
524 REBASE VS. PULL/MERGE
525 ---------------------
526
527 -Originally, `git-svn` recommended that the 'remotes/git-svn' branch be
527 +Originally, 'git-svn' recommended that the 'remotes/git-svn' branch be
528 pulled or merged from. This is because the author favored
529 `git svn set-tree B` to commit a single head rather than the
530 `git svn set-tree A..B` notation to commit multiple commits.
@@ -539,7 +539,7 @@ previous commits in SVN.
539 DESIGN PHILOSOPHY
540 -----------------
541 Merge tracking in Subversion is lacking and doing branched development
542 -with Subversion can be cumbersome as a result. While `git-svn` can track
542 +with Subversion can be cumbersome as a result. While 'git-svn' can track
543 copy history (including branches and tags) for repositories adopting a
544 standard layout, it cannot yet represent merge history that happened
545 inside git back upstream to SVN users. Therefore it is advised that
@@ -550,25 +550,25 @@ CAVEATS
550 -------
551
552 For the sake of simplicity and interoperating with a less-capable system
553 -(SVN), it is recommended that all `git-svn` users clone, fetch and dcommit
554 -directly from the SVN server, and avoid all `git-clone`/`pull`/`merge`/`push`
553 +(SVN), it is recommended that all 'git-svn' users clone, fetch and dcommit
554 +directly from the SVN server, and avoid all 'git-clone'/`pull`/`merge`/`push`
555 operations between git repositories and branches. The recommended
556 method of exchanging code between git branches and users is
557 -`git-format-patch` and `git-am`, or just 'dcommit'ing to the SVN repository.
557 +'git-format-patch' and 'git-am', or just 'dcommit'ing to the SVN repository.
558
559 -Running `git-merge` or `git-pull` is NOT recommended on a branch you
559 +Running 'git-merge' or 'git-pull' is NOT recommended on a branch you
560 plan to 'dcommit' from. Subversion does not represent merges in any
561 reasonable or useful fashion; so users using Subversion cannot see any
562 merges you've made. Furthermore, if you merge or pull from a git branch
563 that is a mirror of an SVN branch, 'dcommit' may commit to the wrong
564 branch.
565
566 -`git-clone` does not clone branches under the refs/remotes/ hierarchy or
567 -any `git-svn` metadata, or config. So repositories created and managed with
568 -using `git-svn` should use `rsync` for cloning, if cloning is to be done
566 +'git-clone' does not clone branches under the refs/remotes/ hierarchy or
567 +any 'git-svn' metadata, or config. So repositories created and managed with
568 +using 'git-svn' should use `rsync` for cloning, if cloning is to be done
569 at all.
570
571 -Since 'dcommit' uses rebase internally, any git branches you `git-push` to
571 +Since 'dcommit' uses rebase internally, any git branches you 'git-push' to
572 before 'dcommit' on will require forcing an overwrite of the existing ref
573 on the remote repository. This is generally considered bad practice,
574 see the linkgit:git-push[1] documentation for details.
@@ -594,7 +594,7 @@ for git to detect them.
594 CONFIGURATION
595 -------------
596
597 -`git-svn` stores [svn-remote] configuration information in the
597 +'git-svn' stores [svn-remote] configuration information in the
598 repository .git/config file. It is similar the core git
599 [remote] sections except 'fetch' keys do not accept glob
600 arguments; but they are instead handled by the 'branches'
@@ -615,7 +615,7 @@ Keep in mind that the '*' (asterisk) wildcard of the local ref
615 however the remote wildcard may be anywhere as long as it's own
616 independent path component (surrounded by '/' or EOL). This
617 type of configuration is not automatically created by 'init' and
618 -should be manually entered with a text-editor or using `git-config`.
618 +should be manually entered with a text-editor or using 'git-config'.
619
620 SEE ALSO
621 --------
Documentation/git-symbolic-ref.txt
+1 -1
@@ -49,7 +49,7 @@ cumbersome. On some platforms, `ln -sf` does not even work as
49 advertised (horrors). Therefore symbolic links are now deprecated
50 and symbolic refs are used by default.
51
52 -`git-symbolic-ref` will exit with status 0 if the contents of the
52 +'git-symbolic-ref' will exit with status 0 if the contents of the
53 symbolic ref were printed correctly, with status 1 if the requested
54 name is not a symbolic ref, or 128 if another error occurs.
55
Documentation/git-tag.txt
+4 -4
@@ -82,7 +82,7 @@ OPTIONS
82
83 CONFIGURATION
84 -------------
85 -By default, `git-tag` in sign-with-default mode (-s) will use your
85 +By default, 'git-tag' in sign-with-default mode (-s) will use your
86 committer identity (of the form "Your Name <your@email.address>") to
87 find a key. If you want to use a different default key, you can specify
88 it in the repository configuration as follows:
@@ -118,12 +118,12 @@ and be done with it.
118
119 . The insane thing.
120 You really want to call the new version "X" too, 'even though'
121 -others have already seen the old one. So just use `git-tag -f`
121 +others have already seen the old one. So just use 'git-tag -f'
122 again, as if you hadn't already published the old one.
123
124 However, Git does *not* (and it should not) change tags behind
125 users back. So if somebody already got the old tag, doing a
126 -`git-pull` on your tree shouldn't just make them overwrite the old
126 +'git-pull' on your tree shouldn't just make them overwrite the old
127 one.
128
129 If somebody got a release tag from you, you cannot just change
@@ -177,7 +177,7 @@ private anchor point tags from the other person.
177
178 You would notice "please pull" messages on the mailing list says
179 repo URL and branch name alone. This is designed to be easily
180 -cut&pasted to a `git-fetch` command line:
180 +cut&pasted to a 'git-fetch' command line:
181
182 ------------
183 Linus, please pull from
Documentation/git-tar-tree.txt
+3 -3
@@ -12,19 +12,19 @@ SYNOPSIS
12
13 DESCRIPTION
14 -----------
15 -THIS COMMAND IS DEPRECATED. Use `git-archive` with `--format=tar`
15 +THIS COMMAND IS DEPRECATED. Use 'git-archive' with `--format=tar`
16 option instead (and move the <base> argument to `--prefix=base/`).
17
18 Creates a tar archive containing the tree structure for the named tree.
19 When <base> is specified it is added as a leading path to the files in the
20 generated tar archive.
21
22 -`git-tar-tree` behaves differently when given a tree ID versus when given
22 +'git-tar-tree' behaves differently when given a tree ID versus when given
23 a commit ID or tag ID. In the first case the current time is used as
24 modification time of each file in the archive. In the latter case the
25 commit time as recorded in the referenced commit object is used instead.
26 Additionally the commit ID is stored in a global extended pax header.
27 -It can be extracted using `git-get-tar-commit-id`.
27 +It can be extracted using 'git-get-tar-commit-id'.
28
29 OPTIONS
30 -------
Documentation/git-update-index.txt
+11 -11
@@ -31,7 +31,7 @@ cleared.
31 See also linkgit:git-add[1] for a more user-friendly way to do some of
32 the most common operations on the index.
33
34 -The way `git-update-index` handles files it is told about can be modified
34 +The way 'git-update-index' handles files it is told about can be modified
35 using the various options:
36
37 OPTIONS
@@ -53,7 +53,7 @@ OPTIONS
53 -q::
54 Quiet. If --refresh finds that the index needs an update, the
55 default behavior is to error out. This option makes
56 - `git-update-index` continue anyway.
56 + 'git-update-index' continue anyway.
57
58 --ignore-submodules:
59 Do not try to update submodules. This option is only respected
@@ -61,7 +61,7 @@ OPTIONS
61
62 --unmerged::
63 If --refresh finds unmerged changes in the index, the default
64 - behavior is to error out. This option makes `git-update-index`
64 + behavior is to error out. This option makes 'git-update-index'
65 continue anyway.
66
67 --ignore-missing::
@@ -91,7 +91,7 @@ OPTIONS
91
92 -g::
93 --again::
94 - Runs `git-update-index` itself on the paths whose index
94 + Runs 'git-update-index' itself on the paths whose index
95 entries are different from those from the `HEAD` commit.
96
97 --unresolve::
@@ -109,7 +109,7 @@ OPTIONS
109
110 --replace::
111 By default, when a file `path` exists in the index,
112 - `git-update-index` refuses an attempt to add `path/file`.
112 + 'git-update-index' refuses an attempt to add `path/file`.
113 Similarly if a file `path/file` exists, a file `path`
114 cannot be added. With --replace flag, existing entries
115 that conflicts with the entry being added are
@@ -145,7 +145,7 @@ up-to-date for mode/content changes. But what it *does* do is to
145 can refresh the index for a file that hasn't been changed but where
146 the stat entry is out of date.
147
148 -For example, you'd want to do this after doing a `git-read-tree`, to link
148 +For example, you'd want to do this after doing a 'git-read-tree', to link
149 up the stat index details with the proper files.
150
151 Using --cacheinfo or --info-only
@@ -186,13 +186,13 @@ back on 3-way merge.
186
187 . mode SP type SP sha1 TAB path
188 +
189 -The second format is to stuff `git-ls-tree` output
189 +The second format is to stuff 'git-ls-tree' output
190 into the index file.
191
192 . mode SP sha1 SP stage TAB path
193 +
194 This format is to put higher order stages into the
195 -index file and matches `git-ls-files --stage` output.
195 +index file and matches 'git-ls-files --stage' output.
196
197 To place a higher stage entry to the index, the path should
198 first be removed by feeding a mode=0 entry for the path, and
@@ -249,8 +249,8 @@ option. To unset, use `--no-assume-unchanged`.
249 The command looks at `core.ignorestat` configuration variable. When
250 this is true, paths updated with `git update-index paths...` and
251 paths updated with other git commands that update both index and
252 -working tree (e.g. `git-apply --index`, `git-checkout-index -u`,
253 -and `git-read-tree -u`) are automatically marked as "assume
252 +working tree (e.g. 'git-apply --index', 'git-checkout-index -u',
253 +and 'git-read-tree -u') are automatically marked as "assume
254 unchanged". Note that "assume unchanged" bit is *not* set if
255 `git update-index --refresh` finds the working tree file matches
256 the index (use `git update-index --really-refresh` if you want
@@ -303,7 +303,7 @@ unreliable, this should be set to 'false' (see linkgit:git-config[1]).
303 This causes the command to ignore differences in file modes recorded
304 in the index and the file mode on the filesystem if they differ only on
305 executable bit. On such an unfortunate filesystem, you may
306 -need to use `git-update-index --chmod=`.
306 +need to use 'git-update-index --chmod='.
307
308 Quite similarly, if `core.symlinks` configuration variable is set
309 to 'false' (see linkgit:git-config[1]), symbolic links are checked out
Documentation/git-upload-archive.txt
+1 -1
@@ -16,7 +16,7 @@ Invoked by 'git-archive --remote' and sends a generated archive to the
16 other end over the git protocol.
17
18 This command is usually not invoked directly by the end user. The UI
19 -for the protocol is on the `git-archive` side, and the program pair
19 +for the protocol is on the 'git-archive' side, and the program pair
20 is meant to be used to get an archive from a remote repository.
21
22 OPTIONS
Documentation/git-upload-pack.txt
+3 -3
@@ -12,13 +12,13 @@ SYNOPSIS
12
13 DESCRIPTION
14 -----------
15 -Invoked by `git-fetch-pack`, learns what
15 +Invoked by 'git-fetch-pack', learns what
16 objects the other side is missing, and sends them after packing.
17
18 This command is usually not invoked directly by the end user.
19 -The UI for the protocol is on the `git-fetch-pack` side, and the
19 +The UI for the protocol is on the 'git-fetch-pack' side, and the
20 program pair is meant to be used to pull updates from a remote
21 -repository. For push operations, see `git-send-pack`.
21 +repository. For push operations, see 'git-send-pack'.
22
23
24 OPTIONS
Documentation/git-var.txt
+1 -1
@@ -20,7 +20,7 @@ OPTIONS
20 Cause the logical variables to be listed. In addition, all the
21 variables of the git configuration file .git/config are listed
22 as well. (However, the configuration variables listing functionality
23 - is deprecated in favor of `git-config -l`.)
23 + is deprecated in favor of 'git-config -l'.)
24
25 EXAMPLE
26 --------
Documentation/git-verify-pack.txt
+1 -1
@@ -14,7 +14,7 @@ SYNOPSIS
14 DESCRIPTION
15 -----------
16 Reads given idx file for packed git archive created with the
17 -`git-pack-objects` command and verifies idx file and the
17 +'git-pack-objects' command and verifies idx file and the
18 corresponding pack file.
19
20 OPTIONS
Documentation/git-verify-tag.txt
+1 -1
@@ -11,7 +11,7 @@ SYNOPSIS
11
12 DESCRIPTION
13 -----------
14 -Validates the gpg signature created by `git-tag`.
14 +Validates the gpg signature created by 'git-tag'.
15
16 OPTIONS
17 -------
Documentation/git-web--browse.txt
+3 -3
@@ -61,7 +61,7 @@ browser.<tool>.path
61 You can explicitly provide a full path to your preferred browser by
62 setting the configuration variable 'browser.<tool>.path'. For example,
63 you can configure the absolute path to firefox by setting
64 -'browser.firefox.path'. Otherwise, `git-web--browse` assumes the tool
64 +'browser.firefox.path'. Otherwise, 'git-web--browse' assumes the tool
65 is available in PATH.
66
67 browser.<tool>.cmd
@@ -70,7 +70,7 @@ browser.<tool>.cmd
70 When the browser, specified by options or configuration variables, is
71 not among the supported ones, then the corresponding
72 'browser.<tool>.cmd' configuration variable will be looked up. If this
73 -variable exists then `git-web--browse` will treat the specified tool
73 +variable exists then 'git-web--browse' will treat the specified tool
74 as a custom command and will use a shell eval to run the command with
75 the URLs passed as arguments.
76
@@ -112,7 +112,7 @@ See linkgit:git-config[1] for more information about this.
112 Author
113 ------
114 Written by Christian Couder <chriscool@tuxfamily.org> and the git-list
115 -<git@vger.kernel.org>, based on `git-mergetool` by Theodore Y. Ts'o.
115 +<git@vger.kernel.org>, based on 'git-mergetool' by Theodore Y. Ts'o.
116
117 Documentation
118 -------------
Documentation/git-whatchanged.txt
+2 -2
@@ -13,8 +13,8 @@ SYNOPSIS
13 DESCRIPTION
14 -----------
15 Shows commit logs and diff output each commit introduces. The
16 -command internally invokes `git-rev-list` piped to
17 -`git-diff-tree`, and takes command line options for both of
16 +command internally invokes 'git-rev-list' piped to
17 +'git-diff-tree', and takes command line options for both of
18 these commands.
19
20 This manual page describes only the most frequently used options.
Documentation/git-write-tree.txt
+4 -4
@@ -16,17 +16,17 @@ Creates a tree object using the current index.
16
17 The index must be in a fully merged state.
18
19 -Conceptually, `git-write-tree` sync()s the current index contents
19 +Conceptually, 'git-write-tree' sync()s the current index contents
20 into a set of tree files.
21 In order to have that match what is actually in your directory right
22 -now, you need to have done a `git-update-index` phase before you did the
23 -`git-write-tree`.
22 +now, you need to have done a 'git-update-index' phase before you did the
23 +'git-write-tree'.
24
25
26 OPTIONS
27 -------
28 --missing-ok::
29 - Normally `git-write-tree` ensures that the objects referenced by the
29 + Normally 'git-write-tree' ensures that the objects referenced by the
30 directory exist in the object database. This option disables this
31 check.
32
Documentation/git.txt
+4 -4
@@ -484,8 +484,8 @@ other
484 a pager.
485
486 'GIT_SSH'::
487 - If this environment variable is set then `git-fetch`
488 - and `git-push` will use this command instead
487 + If this environment variable is set then 'git-fetch'
488 + and 'git-push' will use this command instead
489 of `ssh` when they need to connect to a remote system.
490 The '$GIT_SSH' command will be given exactly two arguments:
491 the 'username@host' (or just 'host') from the URL and the
@@ -501,8 +501,8 @@ for further details.
501
502 'GIT_FLUSH'::
503 If this environment variable is set to "1", then commands such
504 - as `git-blame` (in incremental mode), `git-rev-list`, `git-log`,
505 - and `git-whatchanged` will force a flush of the output stream
504 + as 'git-blame' (in incremental mode), 'git-rev-list', 'git-log',
505 + and 'git-whatchanged' will force a flush of the output stream
506 after each commit-oriented record have been flushed. If this
507 variable is set to "0", the output of these commands will be done
508 using completely buffered I/O. If this environment variable is
Documentation/gitattributes.txt
+8 -8
@@ -87,9 +87,9 @@ Checking-out and checking-in
87
88 These attributes affect how the contents stored in the
89 repository are copied to the working tree files when commands
90 -such as `git-checkout` and `git-merge` run. They also affect how
90 +such as 'git-checkout' and 'git-merge' run. They also affect how
91 git stores the contents you prepare in the working tree in the
92 -repository upon `git-add` and `git-commit`.
92 +repository upon 'git-add' and 'git-commit'.
93
94 `crlf`
95 ^^^^^^
@@ -148,16 +148,16 @@ an irreversible conversion. The safety triggers to prevent such
148 a conversion done to the files in the work tree, but there are a
149 few exceptions. Even though...
150
151 -- `git-add` itself does not touch the files in the work tree, the
151 +- 'git-add' itself does not touch the files in the work tree, the
152 next checkout would, so the safety triggers;
153
154 -- `git-apply` to update a text file with a patch does touch the files
154 +- 'git-apply' to update a text file with a patch does touch the files
155 in the work tree, but the operation is about text files and CRLF
156 conversion is about fixing the line ending inconsistencies, so the
157 safety does not trigger;
158
159 -- `git-diff` itself does not touch the files in the work tree, it is
160 - often run to inspect the changes you intend to next `git-add`. To
159 +- 'git-diff' itself does not touch the files in the work tree, it is
160 + often run to inspect the changes you intend to next 'git-add'. To
161 catch potential problems early, safety triggers.
162
163
@@ -214,7 +214,7 @@ with `crlf`, and then `ident` and fed to `filter`.
214 Generating diff text
215 ~~~~~~~~~~~~~~~~~~~~
216
217 -The attribute `diff` affects if `git-diff` generates textual
217 +The attribute `diff` affects if 'git-diff' generates textual
218 patch for the path or just says `Binary files differ`. It also
219 can affect what line is shown on the hunk header `@@ -k,l +n,m @@`
220 line.
@@ -514,7 +514,7 @@ archive files.
514 If the attribute `export-subst` is set for a file then git will expand
515 several placeholders when adding this file to an archive. The
516 expansion depends on the availability of a commit ID, i.e., if
517 -`git-archive` has been given a tree instead of a commit or a
517 +'git-archive' has been given a tree instead of a commit or a
518 tag then no replacement will be done. The placeholders are the same
519 as those for the option `--pretty=format:` of linkgit:git-log[1],
520 except that they need to be wrapped like this: `$Format:PLACEHOLDERS$`
Documentation/gitcore-tutorial.txt
+81 -81
@@ -42,9 +42,9 @@ one for a totally new project, or an existing working tree that you want
42 to import into git.
43
44 For our first example, we're going to start a totally new repository from
45 -scratch, with no pre-existing files, and we'll call it `git-tutorial`.
45 +scratch, with no pre-existing files, and we'll call it 'git-tutorial'.
46 To start up, create a subdirectory for it, change into that
47 -subdirectory, and initialize the git infrastructure with `git-init`:
47 +subdirectory, and initialize the git infrastructure with 'git-init':
48
49 ------------------------------------------------
50 $ mkdir git-tutorial
@@ -139,7 +139,7 @@ but to actually check in your hard work, you will have to go through two steps:
139 - commit that index file as an object.
140
141 The first step is trivial: when you want to tell git about any changes
142 -to your working tree, you use the `git-update-index` program. That
142 +to your working tree, you use the 'git-update-index' program. That
143 program normally just takes a list of filenames you want to update, but
144 to avoid trivial mistakes, it refuses to add new entries to the index
145 (or remove existing ones) unless you explicitly tell it that you're
@@ -173,14 +173,14 @@ and see two files:
173 which correspond with the objects with names of `557db...` and
174 `f24c7...` respectively.
175
176 -If you want to, you can use `git-cat-file` to look at those objects, but
176 +If you want to, you can use 'git-cat-file' to look at those objects, but
177 you'll have to use the object name, not the filename of the object:
178
179 ----------------
180 $ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
181 ----------------
182
183 -where the `-t` tells `git-cat-file` to tell you what the "type" of the
183 +where the `-t` tells 'git-cat-file' to tell you what the "type" of the
184 object is. git will tell you that you have a "blob" object (i.e., just a
185 regular file), and you can see the contents with
186
@@ -205,7 +205,7 @@ hexadecimal digits in most places.
205 Anyway, as we mentioned previously, you normally never actually take a
206 look at the objects themselves, and typing long 40-character hex
207 names is not something you'd normally want to do. The above digression
208 -was just to show that `git-update-index` did something magical, and
208 +was just to show that 'git-update-index' did something magical, and
209 actually saved away the contents of your files into the git object
210 database.
211
@@ -228,7 +228,7 @@ $ echo "It's a new day for git" >>hello
228
229 and you can now, since you told git about the previous state of `hello`, ask
230 git what has changed in the tree compared to your old index, using the
231 -`git-diff-files` command:
231 +'git-diff-files' command:
232
233 ------------
234 $ git diff-files
@@ -239,7 +239,7 @@ version of a `diff`, but that internal version really just tells you
239 that it has noticed that "hello" has been modified, and that the old object
240 contents it had have been replaced with something else.
241
242 -To make it readable, we can tell `git-diff-files` to output the
242 +To make it readable, we can tell 'git-diff-files' to output the
243 differences as a patch, using the `-p` flag:
244
245 ------------
@@ -255,7 +255,7 @@ index 557db03..263414f 100644
255
256 i.e. the diff of the change we caused by adding another line to `hello`.
257
258 -In other words, `git-diff-files` always shows us the difference between
258 +In other words, 'git-diff-files' always shows us the difference between
259 what is recorded in the index, and what is currently in the working
260 tree. That's very useful.
261
@@ -283,7 +283,7 @@ that in two phases: creating a 'tree' object, and committing that 'tree'
283 object as a 'commit' object together with an explanation of what the
284 tree was all about, along with information of how we came to that state.
285
286 -Creating a tree object is trivial, and is done with `git-write-tree`.
286 +Creating a tree object is trivial, and is done with 'git-write-tree'.
287 There are no options or other input: `git write-tree` will take the
288 current index state, and write an object that describes that whole
289 index. In other words, we're now tying together all the different
@@ -307,23 +307,23 @@ is not a "blob" object, but a "tree" object (you can also use
307 `git cat-file` to actually output the raw object contents, but you'll see
308 mainly a binary mess, so that's less interesting).
309
310 -However -- normally you'd never use `git-write-tree` on its own, because
310 +However -- normally you'd never use 'git-write-tree' on its own, because
311 normally you always commit a tree into a commit object using the
312 -`git-commit-tree` command. In fact, it's easier to not actually use
313 -`git-write-tree` on its own at all, but to just pass its result in as an
314 -argument to `git-commit-tree`.
312 +'git-commit-tree' command. In fact, it's easier to not actually use
313 +'git-write-tree' on its own at all, but to just pass its result in as an
314 +argument to 'git-commit-tree'.
315
316 -`git-commit-tree` normally takes several arguments -- it wants to know
316 +'git-commit-tree' normally takes several arguments -- it wants to know
317 what the 'parent' of a commit was, but since this is the first commit
318 ever in this new repository, and it has no parents, we only need to pass in
319 -the object name of the tree. However, `git-commit-tree` also wants to get a
319 +the object name of the tree. However, 'git-commit-tree' also wants to get a
320 commit message on its standard input, and it will write out the resulting
321 object name for the commit to its standard output.
322
323 And this is where we create the `.git/refs/heads/master` file
324 which is pointed at by `HEAD`. This file is supposed to contain
325 the reference to the top-of-tree of the master branch, and since
326 -that's exactly what `git-commit-tree` spits out, we can do this
326 +that's exactly what 'git-commit-tree' spits out, we can do this
327 all with a sequence of simple shell commands:
328
329 ------------------------------------------------
@@ -345,11 +345,11 @@ instead, and it would have done the above magic scripting for you.
345 Making a change
346 ---------------
347
348 -Remember how we did the `git-update-index` on file `hello` and then we
348 +Remember how we did the 'git-update-index' on file `hello` and then we
349 changed `hello` afterward, and could compare the new state of `hello` with the
350 state we saved in the index file?
351
352 -Further, remember how I said that `git-write-tree` writes the contents
352 +Further, remember how I said that 'git-write-tree' writes the contents
353 of the *index* file to the tree, and thus what we just committed was in
354 fact the *original* contents of the file `hello`, not the new ones. We did
355 that on purpose, to show the difference between the index state, and the
@@ -360,12 +360,12 @@ As before, if we do `git diff-files -p` in our git-tutorial project,
360 we'll still see the same difference we saw last time: the index file
361 hasn't changed by the act of committing anything. However, now that we
362 have committed something, we can also learn to use a new command:
363 -`git-diff-index`.
363 +'git-diff-index'.
364
365 -Unlike `git-diff-files`, which showed the difference between the index
366 -file and the working tree, `git-diff-index` shows the differences
365 +Unlike 'git-diff-files', which showed the difference between the index
366 +file and the working tree, 'git-diff-index' shows the differences
367 between a committed *tree* and either the index file or the working
368 -tree. In other words, `git-diff-index` wants a tree to be diffed
368 +tree. In other words, 'git-diff-index' wants a tree to be diffed
369 against, and before we did the commit, we couldn't do that, because we
370 didn't have anything to diff against.
371
@@ -375,7 +375,7 @@ But now we can do
375 $ git diff-index -p HEAD
376 ----------------
377
378 -(where `-p` has the same meaning as it did in `git-diff-files`), and it
378 +(where `-p` has the same meaning as it did in 'git-diff-files'), and it
379 will show us the same difference, but for a totally different reason.
380 Now we're comparing the working tree not against the index file,
381 but against the tree we just wrote. It just so happens that those two
@@ -390,7 +390,7 @@ $ git diff HEAD
390
391 which ends up doing the above for you.
392
393 -In other words, `git-diff-index` normally compares a tree against the
393 +In other words, 'git-diff-index' normally compares a tree against the
394 working tree, but when given the `\--cached` flag, it is told to
395 instead compare against just the index cache contents, and ignore the
396 current working tree state entirely. Since we just wrote the index
@@ -399,7 +399,7 @@ an empty set of differences, and that's exactly what it does.
399
400 [NOTE]
401 ================
402 -`git-diff-index` really always uses the index for its
402 +'git-diff-index' really always uses the index for its
403 comparisons, and saying that it compares a tree against the working
404 tree is thus not strictly accurate. In particular, the list of
405 files to compare (the "meta-data") *always* comes from the index file,
@@ -428,11 +428,11 @@ $ git update-index hello
428 (note how we didn't need the `\--add` flag this time, since git knew
429 about the file already).
430
431 -Note what happens to the different `git-diff-\*` versions here. After
431 +Note what happens to the different 'git-diff-\*' versions here. After
432 we've updated `hello` in the index, `git diff-files -p` now shows no
433 differences, but `git diff-index -p HEAD` still *does* show that the
434 current state is different from the state we committed. In fact, now
435 -`git-diff-index` shows the same difference whether we use the `--cached`
435 +'git-diff-index' shows the same difference whether we use the `--cached`
436 flag or not, since now the index is coherent with the working tree.
437
438 Now, since we've updated `hello` in the index, we can commit the new
@@ -460,7 +460,7 @@ You've now made your first real git commit. And if you're interested in
460 looking at what `git commit` really does, feel free to investigate:
461 it's a few very simple shell scripts to generate the helpful (?) commit
462 message headers, and a few one-liners that actually do the
463 -commit itself (`git-commit`).
463 +commit itself ('git-commit').
464
465
466 Inspecting Changes
@@ -468,9 +468,9 @@ Inspecting Changes
468
469 While creating changes is useful, it's even more useful if you can tell
470 later what changed. The most useful command for this is another of the
471 -`diff` family, namely `git-diff-tree`.
471 +`diff` family, namely 'git-diff-tree'.
472
473 -`git-diff-tree` can be given two arbitrary trees, and it will tell you the
473 +'git-diff-tree' can be given two arbitrary trees, and it will tell you the
474 differences between them. Perhaps even more commonly, though, you can
475 give it just a single commit object, and it will figure out the parent
476 of that commit itself, and show the difference directly. Thus, to get
@@ -518,15 +518,15 @@ various diff-\* commands compare things.
518 +-----------+
519 ============
520
521 -More interestingly, you can also give `git-diff-tree` the `--pretty` flag,
521 +More interestingly, you can also give 'git-diff-tree' the `--pretty` flag,
522 which tells it to also show the commit message and author and date of the
523 commit, and you can tell it to show a whole series of diffs.
524 Alternatively, you can tell it to be "silent", and not show the diffs at
525 all, but just show the actual commit message.
526
527 -In fact, together with the `git-rev-list` program (which generates a
528 -list of revisions), `git-diff-tree` ends up being a veritable fount of
529 -changes. A trivial (but very useful) script called `git-whatchanged` is
527 +In fact, together with the 'git-rev-list' program (which generates a
528 +list of revisions), 'git-diff-tree' ends up being a veritable fount of
529 +changes. A trivial (but very useful) script called 'git-whatchanged' is
530 included with git which does exactly this, and shows a log of recent
531 activities.
532
@@ -553,14 +553,14 @@ When using the above two commands, the initial commit will be shown.
553 If this is a problem because it is huge, you can hide it by setting
554 the log.showroot configuration variable to false. Having this, you
555 can still show it for each command just adding the `\--root` option,
556 -which is a flag for `git-diff-tree` accepted by both commands.
556 +which is a flag for 'git-diff-tree' accepted by both commands.
557
558 With that, you should now be having some inkling of what git does, and
559 can explore on your own.
560
561 [NOTE]
562 Most likely, you are not directly using the core
563 -git Plumbing commands, but using Porcelain such as `git-add`, `git-rm'
563 +git Plumbing commands, but using Porcelain such as 'git-add', `git-rm'
564 and `git-commit'.
565
566
@@ -595,7 +595,7 @@ pointer to the state you want to tag, but also a small tag name and
595 message, along with optionally a PGP signature that says that yes,
596 you really did
597 that tag. You create these annotated tags with either the `-a` or
598 -`-s` flag to `git-tag`:
598 +`-s` flag to 'git-tag':
599
600 ----------------
601 $ git tag -s <tagname>
@@ -642,7 +642,7 @@ and it will be gone. There's no external repository, and there's no
642 history outside the project you created.
643
644 - if you want to move or duplicate a git repository, you can do so. There
645 - is `git-clone` command, but if all you want to do is just to
645 + is 'git-clone' command, but if all you want to do is just to
646 create a copy of your repository (with all the full history that
647 went along with it), you can do so with a regular
648 `cp -a git-tutorial new-git-tutorial`.
@@ -666,7 +666,7 @@ When copying a remote repository, you'll want to at a minimum update the
666 index cache when you do this, and especially with other peoples'
667 repositories you often want to make sure that the index cache is in some
668 known state (you don't know *what* they've done and not yet checked in),
669 -so usually you'll precede the `git-update-index` with a
669 +so usually you'll precede the 'git-update-index' with a
670
671 ----------------
672 $ git read-tree --reset HEAD
@@ -674,7 +674,7 @@ $ git update-index --refresh
674 ----------------
675
676 which will force a total index re-build from the tree pointed to by `HEAD`.
677 -It resets the index contents to `HEAD`, and then the `git-update-index`
677 +It resets the index contents to `HEAD`, and then the 'git-update-index'
678 makes sure to match up all index entries with the checked-out files.
679 If the original repository had uncommitted changes in its
680 working tree, `git update-index --refresh` notices them and
@@ -689,8 +689,8 @@ $ git reset
689 and in fact a lot of the common git command combinations can be scripted
690 with the `git xyz` interfaces. You can learn things by just looking
691 at what the various git scripts do. For example, `git reset` used to be
692 -the above two lines implemented in `git-reset`, but some things like
693 -`git-status` and `git-commit` are slightly more complex scripts around
692 +the above two lines implemented in 'git-reset', but some things like
693 +'git-status' and 'git-commit' are slightly more complex scripts around
694 the basic git commands.
695
696 Many (most?) public remote repositories will not contain any of
@@ -729,7 +729,7 @@ where the `-u` flag means that you want the checkout to keep the index
729 up-to-date (so that you don't have to refresh it afterward), and the
730 `-a` flag means "check out all files" (if you have a stale copy or an
731 older version of a checked out tree you may also need to add the `-f`
732 -flag first, to tell `git-checkout-index` to *force* overwriting of any old
732 +flag first, to tell 'git-checkout-index' to *force* overwriting of any old
733 files).
734
735 Again, this can all be simplified with
@@ -776,7 +776,7 @@ to it.
776 ================================================
777 If you make the decision to start your new branch at some
778 other point in the history than the current `HEAD`, you can do so by
779 -just telling `git-checkout` what the base of the checkout would be.
779 +just telling 'git-checkout' what the base of the checkout would be.
780 In other words, if you have an earlier tag or branch, you'd just do
781
782 ------------
@@ -819,7 +819,7 @@ $ git branch <branchname> [startingpoint]
819
820 which will simply _create_ the branch, but will not do anything further.
821 You can then later -- once you decide that you want to actually develop
822 -on that branch -- switch to that branch with a regular `git-checkout`
822 +on that branch -- switch to that branch with a regular 'git-checkout'
823 with the branchname as the argument.
824
825
@@ -881,7 +881,7 @@ source.
881 Anyway, let's exit `gitk` (`^Q` or the File menu), and decide that we want
882 to merge the work we did on the `mybranch` branch into the `master`
883 branch (which is currently our `HEAD` too). To do that, there's a nice
884 -script called `git-merge`, which wants to know which branches you want
884 +script called 'git-merge', which wants to know which branches you want
885 to resolve and what the merge is all about:
886
887 ------------
@@ -925,7 +925,7 @@ $ git commit -i hello
925
926 which will very loudly warn you that you're now committing a merge
927 (which is correct, so never mind), and you can write a small merge
928 -message about your adventures in `git-merge`-land.
928 +message about your adventures in 'git-merge'-land.
929
930 After you're done, start up `gitk \--all` to see graphically what the
931 history looks like. Notice that `mybranch` still exists, and you can
@@ -967,21 +967,21 @@ branch head. Please see linkgit:git-rev-parse[1] if you want to
967 see more complex cases.
968
969 [NOTE]
970 -Without the '--more=1' option, `git-show-branch` would not output the
970 +Without the '--more=1' option, 'git-show-branch' would not output the
971 '[master^]' commit, as '[mybranch]' commit is a common ancestor of
972 both 'master' and 'mybranch' tips. Please see linkgit:git-show-branch[1]
973 for details.
974
975 [NOTE]
976 If there were more commits on the 'master' branch after the merge, the
977 -merge commit itself would not be shown by `git-show-branch` by
977 +merge commit itself would not be shown by 'git-show-branch' by
978 default. You would need to provide '--sparse' option to make the
979 merge commit visible in this case.
980
981 Now, let's pretend you are the one who did all the work in
982 `mybranch`, and the fruit of your hard work has finally been merged
983 to the `master` branch. Let's go back to `mybranch`, and run
984 -`git-merge` to get the "upstream changes" back to your branch.
984 +'git-merge' to get the "upstream changes" back to your branch.
985
986 ------------
987 $ git checkout mybranch
@@ -1023,12 +1023,12 @@ Merging external work
1023 It's usually much more common that you merge with somebody else than
1024 merging with your own branches, so it's worth pointing out that git
1025 makes that very easy too, and in fact, it's not that different from
1026 -doing a `git-merge`. In fact, a remote merge ends up being nothing
1026 +doing a 'git-merge'. In fact, a remote merge ends up being nothing
1027 more than "fetch the work from a remote repository into a temporary tag"
1028 -followed by a `git-merge`.
1028 +followed by a 'git-merge'.
1029
1030 Fetching from a remote repository is done by, unsurprisingly,
1031 -`git-fetch`:
1031 +'git-fetch':
1032
1033 ----------------
1034 $ git fetch <remote-repository>
@@ -1095,7 +1095,7 @@ The 'commit walkers' are sometimes also called 'dumb
1095 transports', because they do not require any git aware smart
1096 server like git Native transport does. Any stock HTTP server
1097 that does not even support directory index would suffice. But
1098 -you must prepare your repository with `git-update-server-info`
1098 +you must prepare your repository with 'git-update-server-info'
1099 to help dumb transport downloaders.
1100
1101 Once you fetch from the remote repository, you `merge` that
@@ -1115,7 +1115,7 @@ argument.
1115 [NOTE]
1116 You could do without using any branches at all, by
1117 keeping as many local repositories as you would like to have
1118 -branches, and merging between them with `git-pull`, just like
1118 +branches, and merging between them with 'git-pull', just like
1119 you merge between branches. The advantage of this approach is
1120 that it lets you keep a set of files for each `branch` checked
1121 out and you may find it easier to switch back and forth if you
@@ -1132,7 +1132,7 @@ like this:
1132 $ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
1133 ------------------------------------------------
1134
1135 -and use the "linus" keyword with `git-pull` instead of the full URL.
1135 +and use the "linus" keyword with 'git-pull' instead of the full URL.
1136
1137 Examples.
1138
@@ -1168,7 +1168,7 @@ $ git show-branch --more=2 master mybranch
1168 +* [master^] Some fun.
1169 ------------
1170
1171 -Remember, before running `git-merge`, our `master` head was at
1171 +Remember, before running 'git-merge', our `master` head was at
1172 "Some fun." commit, while our `mybranch` head was at "Some
1173 work." commit.
1174
@@ -1195,7 +1195,7 @@ Now we are ready to experiment with the merge by hand.
1195
1196 `git merge` command, when merging two branches, uses 3-way merge
1197 algorithm. First, it finds the common ancestor between them.
1198 -The command it uses is `git-merge-base`:
1198 +The command it uses is 'git-merge-base':
1199
1200 ------------
1201 $ mb=$(git merge-base HEAD mybranch)
@@ -1219,7 +1219,7 @@ this:
1219 $ git read-tree -m -u $mb HEAD mybranch
1220 ------------
1221
1222 -This is the same `git-read-tree` command we have already seen,
1222 +This is the same 'git-read-tree' command we have already seen,
1223 but it takes three trees, unlike previous examples. This reads
1224 the contents of each tree into different 'stage' in the index
1225 file (the first tree goes to stage 1, the second to stage 2,
@@ -1260,8 +1260,8 @@ $ git ls-files --unmerged
1260
1261 The next step of merging is to merge these three versions of the
1262 file, using 3-way merge. This is done by giving
1263 -`git-merge-one-file` command as one of the arguments to
1264 -`git-merge-index` command:
1263 +'git-merge-one-file' command as one of the arguments to
1264 +'git-merge-index' command:
1265
1266 ------------
1267 $ git merge-index git-merge-one-file hello
@@ -1271,7 +1271,7 @@ ERROR: Merge conflict in hello.
1271 fatal: merge program failed
1272 ------------
1273
1274 -`git-merge-one-file` script is called with parameters to
1274 +'git-merge-one-file' script is called with parameters to
1275 describe those three versions, and is responsible to leave the
1276 merge results in the working tree.
1277 It is a fairly straightforward shell script, and
@@ -1290,9 +1290,9 @@ $ git ls-files --stage
1290 ------------
1291
1292 This is the state of the index file and the working file after
1293 -`git-merge` returns control back to you, leaving the conflicting
1293 +'git-merge' returns control back to you, leaving the conflicting
1294 merge for you to resolve. Notice that the path `hello` is still
1295 -unmerged, and what you see with `git-diff` at this point is
1295 +unmerged, and what you see with 'git-diff' at this point is
1296 differences since stage 2 (i.e. your version).
1297
1298
@@ -1320,7 +1320,7 @@ how git repositories at `kernel.org` are managed.
1320 Publishing the changes from your local (private) repository to
1321 your remote (public) repository requires a write privilege on
1322 the remote machine. You need to have an SSH account there to
1323 -run a single command, `git-receive-pack`.
1323 +run a single command, 'git-receive-pack'.
1324
1325 First, you need to create an empty repository on the remote
1326 machine that will house your public repository. This empty
@@ -1329,8 +1329,8 @@ into it later. Obviously, this repository creation needs to be
1329 done only once.
1330
1331 [NOTE]
1332 -`git-push` uses a pair of programs,
1333 -`git-send-pack` on your local machine, and `git-receive-pack`
1332 +'git-push' uses a pair of programs,
1333 +'git-send-pack' on your local machine, and 'git-receive-pack'
1334 on the remote machine. The communication between the two over
1335 the network internally uses an SSH connection.
1336
@@ -1345,7 +1345,7 @@ $ mkdir my-git.git
1345 ------------
1346
1347 Then, make that directory into a git repository by running
1348 -`git-init`, but this time, since its name is not the usual
1348 +'git-init', but this time, since its name is not the usual
1349 `.git`, we do things slightly differently:
1350
1351 ------------
@@ -1354,7 +1354,7 @@ $ GIT_DIR=my-git.git git init
1354
1355 Make sure this directory is available for others you want your
1356 changes to be pulled by via the transport of your choice. Also
1357 -you need to make sure that you have the `git-receive-pack`
1357 +you need to make sure that you have the 'git-receive-pack'
1358 program on the `$PATH`.
1359
1360 [NOTE]
@@ -1362,7 +1362,7 @@ Many installations of sshd do not invoke your shell as the login
1362 shell when you directly run programs; what this means is that if
1363 your login shell is `bash`, only `.bashrc` is read and not
1364 `.bash_profile`. As a workaround, make sure `.bashrc` sets up
1365 -`$PATH` so that you can run `git-receive-pack` program.
1365 +`$PATH` so that you can run 'git-receive-pack' program.
1366
1367 [NOTE]
1368 If you plan to publish this repository to be accessed over http,
@@ -1407,7 +1407,7 @@ $ git repack
1407
1408 will do it for you. If you followed the tutorial examples, you
1409 would have accumulated about 17 objects in `.git/objects/??/`
1410 -directories by now. `git-repack` tells you how many objects it
1410 +directories by now. 'git-repack' tells you how many objects it
1411 packed, and stores the packed file in `.git/objects/pack`
1412 directory.
1413
@@ -1420,7 +1420,7 @@ them together. The former holds all the data from the objects
1420 in the pack, and the latter holds the index for random
1421 access.
1422
1423 -If you are paranoid, running `git-verify-pack` command would
1423 +If you are paranoid, running 'git-verify-pack' command would
1424 detect if you have a corrupt pack, but do not worry too much.
1425 Our programs are always perfect ;-).
1426
@@ -1487,17 +1487,17 @@ If other people are pulling from your repository over dumb
1487 transport protocols (HTTP), you need to keep this repository
1488 'dumb transport friendly'. After `git init`,
1489 `$GIT_DIR/hooks/post-update` copied from the standard templates
1490 -would contain a call to `git-update-server-info` but the
1490 +would contain a call to 'git-update-server-info' but the
1491 `post-update` hook itself is disabled by default -- enable it
1492 -with `chmod +x post-update`. This makes sure `git-update-server-info`
1492 +with `chmod +x post-update`. This makes sure 'git-update-server-info'
1493 keeps the necessary files up-to-date.
1494
1495 3. Push into the public repository from your primary
1496 repository.
1497
1498 -4. `git-repack` the public repository. This establishes a big
1498 +4. 'git-repack' the public repository. This establishes a big
1499 pack that contains the initial set of objects as the
1500 - baseline, and possibly `git-prune` if the transport
1500 + baseline, and possibly 'git-prune' if the transport
1501 used for pulling from your repository supports packed
1502 repositories.
1503
@@ -1518,7 +1518,7 @@ You can repack this private repository whenever you feel like.
1518 A recommended work cycle for a "subsystem maintainer" who works
1519 on that project and has an own "public repository" goes like this:
1520
1521 -1. Prepare your work repository, by `git-clone` the public
1521 +1. Prepare your work repository, by 'git-clone' the public
1522 repository of the "project lead". The URL used for the
1523 initial cloning is stored in the remote.origin.url
1524 configuration variable.
@@ -1533,7 +1533,7 @@ on that project and has an own "public repository" goes like this:
1533 point at the repository you are borrowing from.
1534
1535 4. Push into the public repository from your primary
1536 - repository. Run `git-repack`, and possibly `git-prune` if the
1536 + repository. Run 'git-repack', and possibly 'git-prune' if the
1537 transport used for pulling from your repository supports
1538 packed repositories.
1539
@@ -1550,7 +1550,7 @@ like.
1550 "project lead" and possibly your "sub-subsystem
1551 maintainers" to pull from it.
1552
1553 -7. Every once in a while, `git-repack` the public repository.
1553 +7. Every once in a while, 'git-repack' the public repository.
1554 Go back to step 5. and continue working.
1555
1556
@@ -1558,7 +1558,7 @@ A recommended work cycle for an "individual developer" who does
1558 not have a "public" repository is somewhat different. It goes
1559 like this:
1560
1561 -1. Prepare your work repository, by `git-clone` the public
1561 +1. Prepare your work repository, by 'git-clone' the public
1562 repository of the "project lead" (or a "subsystem
1563 maintainer", if you work on a subsystem). The URL used for
1564 the initial cloning is stored in the remote.origin.url
Documentation/gitcvs-migration.txt
+6 -6
@@ -47,25 +47,25 @@ them first before running git pull.
47 [NOTE]
48 ================================
49 The `pull` command knows where to get updates from because of certain
50 -configuration variables that were set by the first `git-clone`
50 +configuration variables that were set by the first 'git-clone'
51 command; see `git config -l` and the linkgit:git-config[1] man
52 page for details.
53 ================================
54
55 You can update the shared repository with your changes by first committing
56 -your changes, and then using the `git-push` command:
56 +your changes, and then using the 'git-push' command:
57
58 ------------------------------------------------
59 $ git push origin master
60 ------------------------------------------------
61
62 to "push" those commits to the shared repository. If someone else has
63 -updated the repository more recently, `git-push`, like `cvs commit`, will
63 +updated the repository more recently, 'git-push', like `cvs commit`, will
64 complain, in which case you must pull any changes before attempting the
65 push again.
66
67 -In the `git-push` command above we specify the name of the remote branch
68 -to update (`master`). If we leave that out, `git-push` tries to update
67 +In the 'git-push' command above we specify the name of the remote branch
68 +to update (`master`). If we leave that out, 'git-push' tries to update
69 any branches in the remote repository that have the same name as a branch
70 in the local repository. So the last `push` can be done with either of:
71
@@ -118,7 +118,7 @@ Importing a CVS archive
118 First, install version 2.1 or higher of cvsps from
119 link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
120 sure it is in your path. Then cd to a checked out CVS working directory
121 -of the project you are interested in and run `git-cvsimport`:
121 +of the project you are interested in and run 'git-cvsimport':
122
123 -------------------------------------------
124 $ git cvsimport -C <destination> <module>
Documentation/gitdiffcore.txt
+15 -15
@@ -12,7 +12,7 @@ SYNOPSIS
12 DESCRIPTION
13 -----------
14
15 -The diff commands `git-diff-index`, `git-diff-files`, and `git-diff-tree`
15 +The diff commands 'git-diff-index', 'git-diff-files', and 'git-diff-tree'
16 can be told to manipulate differences they find in
17 unconventional ways before showing `diff` output. The manipulation
18 is collectively called "diffcore transformation". This short note
@@ -23,18 +23,18 @@ that is easier to understand than the conventional kind.
23 The chain of operation
24 ----------------------
25
26 -The `git-diff-{asterisk}` family works by first comparing two sets of
26 +The 'git-diff-{asterisk}' family works by first comparing two sets of
27 files:
28
29 - - `git-diff-index` compares contents of a "tree" object and the
29 + - 'git-diff-index' compares contents of a "tree" object and the
30 working directory (when '\--cached' flag is not used) or a
31 "tree" object and the index file (when '\--cached' flag is
32 used);
33
34 - - `git-diff-files` compares contents of the index file and the
34 + - 'git-diff-files' compares contents of the index file and the
35 working directory;
36
37 - - `git-diff-tree` compares contents of two "tree" objects;
37 + - 'git-diff-tree' compares contents of two "tree" objects;
38
39 In all of these cases, the commands themselves compare
40 corresponding paths in the two sets of files. The result of
@@ -61,12 +61,12 @@ into another list. There are currently 6 such transformations:
61 - diffcore-pickaxe
62 - diffcore-order
63
64 -These are applied in sequence. The set of filepairs `git-diff-{asterisk}`
64 +These are applied in sequence. The set of filepairs 'git-diff-{asterisk}'
65 commands find are used as the input to diffcore-pathspec, and
66 the output from diffcore-pathspec is used as the input to the
67 next transformation. The final result is then passed to the
68 output routine and generates either diff-raw format (see Output
69 -format sections of the manual for `git-diff-{asterisk}` commands) or
69 +format sections of the manual for 'git-diff-{asterisk}' commands) or
70 diff-patch format.
71
72
@@ -75,7 +75,7 @@ diffcore-pathspec: For Ignoring Files Outside Our Consideration
75
76 The first transformation in the chain is diffcore-pathspec, and
77 is controlled by giving the pathname parameters to the
78 -`git-diff-{asterisk}` commands on the command line. The pathspec is used
78 +'git-diff-{asterisk}' commands on the command line. The pathspec is used
79 to limit the world diff operates in. It removes the filepairs
80 outside the specified set of pathnames. E.g. If the input set
81 of filepairs included:
@@ -88,7 +88,7 @@ but the command invocation was `git diff-files myfile`, then the
88 junkfile entry would be removed from the list because only "myfile"
89 is under consideration.
90
91 -Implementation note. For performance reasons, `git-diff-tree`
91 +Implementation note. For performance reasons, 'git-diff-tree'
92 uses the pathname parameters on the command line to cull set of
93 filepairs it feeds the diffcore mechanism itself, and does not
94 use diffcore-pathspec, but the end result is the same.
@@ -98,7 +98,7 @@ diffcore-break: For Splitting Up "Complete Rewrites"
98 ----------------------------------------------------
99
100 The second transformation in the chain is diffcore-break, and is
101 -controlled by the -B option to the `git-diff-{asterisk}` commands. This is
101 +controlled by the -B option to the 'git-diff-{asterisk}' commands. This is
102 used to detect a filepair that represents "complete rewrite" and
103 break such filepair into two filepairs that represent delete and
104 create. E.g. If the input contained this filepair:
@@ -134,7 +134,7 @@ diffcore-rename: For Detection Renames and Copies
134
135 This transformation is used to detect renames and copies, and is
136 controlled by the -M option (to detect renames) and the -C option
137 -(to detect copies as well) to the `git-diff-{asterisk}` commands. If the
137 +(to detect copies as well) to the 'git-diff-{asterisk}' commands. If the
138 input contained these filepairs:
139
140 ------------------------------------------------
@@ -179,11 +179,11 @@ number after the "-M" or "-C" option (e.g. "-M8" to tell it to use
179 8/10 = 80%).
180
181 Note. When the "-C" option is used with `\--find-copies-harder`
182 -option, `git-diff-{asterisk}` commands feed unmodified filepairs to
182 +option, 'git-diff-{asterisk}' commands feed unmodified filepairs to
183 diffcore mechanism as well as modified ones. This lets the copy
184 detector consider unmodified files as copy source candidates at
185 the expense of making it slower. Without `\--find-copies-harder`,
186 -`git-diff-{asterisk}` commands can detect copies only if the file that was
186 +'git-diff-{asterisk}' commands can detect copies only if the file that was
187 copied happened to have been modified in the same changeset.
188
189
@@ -234,7 +234,7 @@ diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
234
235 This transformation is used to find filepairs that represent
236 changes that touch a specified string, and is controlled by the
237 --S option and the `\--pickaxe-all` option to the `git-diff-{asterisk}`
237 +-S option and the `\--pickaxe-all` option to the 'git-diff-{asterisk}'
238 commands.
239
240 When diffcore-pickaxe is in use, it checks if there are
@@ -257,7 +257,7 @@ diffcore-order: For Sorting the Output Based on Filenames
257
258 This is used to reorder the filepairs according to the user's
259 (or project's) taste, and is controlled by the -O option to the
260 -`git-diff-{asterisk}` commands.
260 +'git-diff-{asterisk}' commands.
261
262 This takes a text file each of whose lines is a shell glob
263 pattern. Filepairs that match a glob pattern on an earlier line
Documentation/githooks.txt
+37 -37
@@ -15,7 +15,7 @@ DESCRIPTION
15
16 Hooks are little scripts you can place in `$GIT_DIR/hooks`
17 directory to trigger action at certain points. When
18 -`git-init` is run, a handful example hooks are copied in the
18 +'git-init' is run, a handful example hooks are copied in the
19 `hooks` directory of the new repository, but by default they are
20 all disabled. To enable a hook, rename it by removing its `.sample`
21 suffix.
@@ -25,10 +25,10 @@ This document describes the currently defined hooks.
25 applypatch-msg
26 --------------
27
28 -This hook is invoked by `git-am` script. It takes a single
28 +This hook is invoked by 'git-am' script. It takes a single
29 parameter, the name of the file that holds the proposed commit
30 log message. Exiting with non-zero status causes
31 -`git-am` to abort before applying the patch.
31 +'git-am' to abort before applying the patch.
32
33 The hook is allowed to edit the message file in place, and can
34 be used to normalize the message into some project standard
@@ -41,7 +41,7 @@ The default 'applypatch-msg' hook, when enabled, runs the
41 pre-applypatch
42 --------------
43
44 -This hook is invoked by `git-am`. It takes no parameter, and is
44 +This hook is invoked by 'git-am'. It takes no parameter, and is
45 invoked after the patch is applied, but before a commit is made.
46
47 If it exits with non-zero status, then the working tree will not be
@@ -56,33 +56,33 @@ The default 'pre-applypatch' hook, when enabled, runs the
56 post-applypatch
57 ---------------
58
59 -This hook is invoked by `git-am`. It takes no parameter,
59 +This hook is invoked by 'git-am'. It takes no parameter,
60 and is invoked after the patch is applied and a commit is made.
61
62 This hook is meant primarily for notification, and cannot affect
63 -the outcome of `git-am`.
63 +the outcome of 'git-am'.
64
65 pre-commit
66 ----------
67
68 -This hook is invoked by `git-commit`, and can be bypassed
68 +This hook is invoked by 'git-commit', and can be bypassed
69 with `\--no-verify` option. It takes no parameter, and is
70 invoked before obtaining the proposed commit log message and
71 making a commit. Exiting with non-zero status from this script
72 -causes the `git-commit` to abort.
72 +causes the 'git-commit' to abort.
73
74 The default 'pre-commit' hook, when enabled, catches introduction
75 of lines with trailing whitespaces and aborts the commit when
76 such a line is found.
77
78 -All the `git-commit` hooks are invoked with the environment
78 +All the 'git-commit' hooks are invoked with the environment
79 variable `GIT_EDITOR=:` if the command will not bring up an editor
80 to modify the commit message.
81
82 prepare-commit-msg
83 ------------------
84
85 -This hook is invoked by `git-commit` right after preparing the
85 +This hook is invoked by 'git-commit' right after preparing the
86 default log message, and before the editor is started.
87
88 It takes one to three parameters. The first is the name of the file
@@ -94,7 +94,7 @@ commit is a merge or a `.git/MERGE_MSG` file exists); `squash`
94 (if a `.git/SQUASH_MSG` file exists); or `commit`, followed by
95 a commit SHA1 (if a `\-c`, `\-C` or `\--amend` option was given).
96
97 -If the exit status is non-zero, `git-commit` will abort.
97 +If the exit status is non-zero, 'git-commit' will abort.
98
99 The purpose of the hook is to edit the message file in place, and
100 it is not suppressed by the `\--no-verify` option. A non-zero exit
@@ -107,10 +107,10 @@ out the `Conflicts:` part of a merge's commit message.
107 commit-msg
108 ----------
109
110 -This hook is invoked by `git-commit`, and can be bypassed
110 +This hook is invoked by 'git-commit', and can be bypassed
111 with `\--no-verify` option. It takes a single parameter, the
112 name of the file that holds the proposed commit log message.
113 -Exiting with non-zero status causes the `git-commit` to
113 +Exiting with non-zero status causes the 'git-commit' to
114 abort.
115
116 The hook is allowed to edit the message file in place, and can
@@ -124,21 +124,21 @@ The default 'commit-msg' hook, when enabled, detects duplicate
124 post-commit
125 -----------
126
127 -This hook is invoked by `git-commit`. It takes no
127 +This hook is invoked by 'git-commit'. It takes no
128 parameter, and is invoked after a commit is made.
129
130 This hook is meant primarily for notification, and cannot affect
131 -the outcome of `git-commit`.
131 +the outcome of 'git-commit'.
132
133 post-checkout
134 -----------
135
136 -This hook is invoked when a `git-checkout` is run after having updated the
136 +This hook is invoked when a 'git-checkout' is run after having updated the
137 worktree. The hook is given three parameters: the ref of the previous HEAD,
138 the ref of the new HEAD (which may or may not have changed), and a flag
139 indicating whether the checkout was a branch checkout (changing branches,
140 flag=1) or a file checkout (retrieving a file from the index, flag=0).
141 -This hook cannot affect the outcome of `git-checkout`.
141 +This hook cannot affect the outcome of 'git-checkout'.
142
143 This hook can be used to perform repository validity checks, auto-display
144 differences from the previous HEAD if different, or set working dir metadata
@@ -147,10 +147,10 @@ properties.
147 post-merge
148 -----------
149
150 -This hook is invoked by `git-merge`, which happens when a `git-pull`
150 +This hook is invoked by 'git-merge', which happens when a 'git-pull'
151 is done on a local repository. The hook takes a single parameter, a status
152 flag specifying whether or not the merge being done was a squash merge.
153 -This hook cannot affect the outcome of `git-merge` and is not executed,
153 +This hook cannot affect the outcome of 'git-merge' and is not executed,
154 if the merge failed due to conflicts.
155
156 This hook can be used in conjunction with a corresponding pre-commit hook to
@@ -162,8 +162,8 @@ for an example of how to do this.
162 pre-receive
163 -----------
164
165 -This hook is invoked by `git-receive-pack` on the remote repository,
166 -which happens when a `git-push` is done on a local repository.
165 +This hook is invoked by 'git-receive-pack' on the remote repository,
166 +which happens when a 'git-push' is done on a local repository.
167 Just before starting to update refs on the remote repository, the
168 pre-receive hook is invoked. Its exit status determines the success
169 or failure of the update.
@@ -184,15 +184,15 @@ updated. If the hook exits with zero, updating of individual refs can
184 still be prevented by the <<update,'update'>> hook.
185
186 Both standard output and standard error output are forwarded to
187 -`git-send-pack` on the other end, so you can simply `echo` messages
187 +'git-send-pack' on the other end, so you can simply `echo` messages
188 for the user.
189
190 [[update]]
191 update
192 ------
193
194 -This hook is invoked by `git-receive-pack` on the remote repository,
195 -which happens when a `git-push` is done on a local repository.
194 +This hook is invoked by 'git-receive-pack' on the remote repository,
195 +which happens when a 'git-push' is done on a local repository.
196 Just before updating the ref on the remote repository, the update hook
197 is invoked. Its exit status determines the success or failure of
198 the ref update.
@@ -205,7 +205,7 @@ three parameters:
205 - and the new objectname to be stored in the ref.
206
207 A zero exit from the update hook allows the ref to be updated.
208 -Exiting with a non-zero status prevents `git-receive-pack`
208 +Exiting with a non-zero status prevents 'git-receive-pack'
209 from updating that ref.
210
211 This hook can be used to prevent 'forced' update on certain refs by
@@ -223,7 +223,7 @@ implement access control which is finer grained than the one
223 based on filesystem group.
224
225 Both standard output and standard error output are forwarded to
226 -`git-send-pack` on the other end, so you can simply `echo` messages
226 +'git-send-pack' on the other end, so you can simply `echo` messages
227 for the user.
228
229 The default 'update' hook, when enabled--and with
@@ -234,8 +234,8 @@ unannotated tags to be pushed.
234 post-receive
235 ------------
236
237 -This hook is invoked by `git-receive-pack` on the remote repository,
238 -which happens when a `git-push` is done on a local repository.
237 +This hook is invoked by 'git-receive-pack' on the remote repository,
238 +which happens when a 'git-push' is done on a local repository.
239 It executes on the remote repository once after all the refs have
240 been updated.
241
@@ -244,7 +244,7 @@ arguments, but gets the same information as the
244 <<pre-receive,'pre-receive'>>
245 hook does on its standard input.
246
247 -This hook does not affect the outcome of `git-receive-pack`, as it
247 +This hook does not affect the outcome of 'git-receive-pack', as it
248 is called after the real work is done.
249
250 This supersedes the <<post-update,'post-update'>> hook in that it gets
@@ -252,7 +252,7 @@ both old and new values of all the refs in addition to their
252 names.
253
254 Both standard output and standard error output are forwarded to
255 -`git-send-pack` on the other end, so you can simply `echo` messages
255 +'git-send-pack' on the other end, so you can simply `echo` messages
256 for the user.
257
258 The default 'post-receive' hook is empty, but there is
@@ -264,8 +264,8 @@ emails.
264 post-update
265 -----------
266
267 -This hook is invoked by `git-receive-pack` on the remote repository,
268 -which happens when a `git-push` is done on a local repository.
267 +This hook is invoked by 'git-receive-pack' on the remote repository,
268 +which happens when a 'git-push' is done on a local repository.
269 It executes on the remote repository once after all the refs have
270 been updated.
271
@@ -273,7 +273,7 @@ It takes a variable number of parameters, each of which is the
273 name of ref that was actually updated.
274
275 This hook is meant primarily for notification, and cannot affect
276 -the outcome of `git-receive-pack`.
276 +the outcome of 'git-receive-pack'.
277
278 The 'post-update' hook can tell what are the heads that were pushed,
279 but it does not know what their original and updated values are,
@@ -283,20 +283,20 @@ updated values of the refs. You might consider it instead if you need
283 them.
284
285 When enabled, the default 'post-update' hook runs
286 -`git-update-server-info` to keep the information used by dumb
286 +'git-update-server-info' to keep the information used by dumb
287 transports (e.g., HTTP) up-to-date. If you are publishing
288 a git repository that is accessible via HTTP, you should
289 probably enable this hook.
290
291 Both standard output and standard error output are forwarded to
292 -`git-send-pack` on the other end, so you can simply `echo` messages
292 +'git-send-pack' on the other end, so you can simply `echo` messages
293 for the user.
294
295 pre-auto-gc
296 -----------
297
298 -This hook is invoked by `git-gc --auto`. It takes no parameter, and
299 -exiting with non-zero status from this script causes the `git-gc --auto`
298 +This hook is invoked by 'git-gc --auto'. It takes no parameter, and
299 +exiting with non-zero status from this script causes the 'git-gc --auto'
300 to abort.
301
302 GIT
Documentation/gitignore.txt
+2 -2
@@ -51,10 +51,10 @@ the user's editor of choice) generally go into a file specified by
51 `core.excludesfile` in the user's `~/.gitconfig`.
52
53 The underlying git plumbing tools, such as
54 -`git-ls-files` and `git-read-tree`, read
54 +'git-ls-files' and 'git-read-tree', read
55 `gitignore` patterns specified by command-line options, or from
56 files specified by command-line options. Higher-level git
57 -tools, such as `git-status` and `git-add`,
57 +tools, such as 'git-status' and 'git-add',
58 use patterns from the sources specified above.
59
60 Patterns have the following format:
Documentation/gitk.txt
+1 -1
@@ -22,7 +22,7 @@ git repository.
22 OPTIONS
23 -------
24 To control which revisions to shown, the command takes options applicable to
25 -the `git-rev-list` command (see linkgit:git-rev-list[1]).
25 +the 'git-rev-list' command (see linkgit:git-rev-list[1]).
26 This manual page describes only the most
27 frequently used options.
28
Documentation/gitrepository-layout.txt
+9 -9
@@ -64,7 +64,7 @@ objects/info/packs::
64 are available in this object store. Whenever a pack is
65 added or removed, `git update-server-info` should be run
66 to keep this file up-to-date if the repository is
67 - published for dumb transports. `git-repack` does this
67 + published for dumb transports. 'git-repack' does this
68 by default.
69
70 objects/info/alternates::
@@ -85,7 +85,7 @@ objects/info/http-alternates::
85
86 refs::
87 References are stored in subdirectories of this
88 - directory. The `git-prune` command knows to keep
88 + directory. The 'git-prune' command knows to keep
89 objects reachable from refs found in this directory and
90 its subdirectories.
91
@@ -125,7 +125,7 @@ details.
125
126 branches::
127 A slightly deprecated way to store shorthands to be used
128 - to specify URL to `git-fetch`, `git-pull` and `git-push`
128 + to specify URL to 'git-fetch', 'git-pull' and 'git-push'
129 commands is to store a file in `branches/<name>` and
130 give 'name' to these commands in place of 'repository'
131 argument.
@@ -133,7 +133,7 @@ branches::
133 hooks::
134 Hooks are customization scripts used by various git
135 commands. A handful of sample hooks are installed when
136 - `git-init` is run, but all of them are disabled by
136 + 'git-init' is run, but all of them are disabled by
137 default. To enable, they need to be made executable.
138 Read linkgit:githooks[5] for more details about
139 each hook.
@@ -150,10 +150,10 @@ info/refs::
150 This file helps dumb transports discover what refs are
151 available in this repository. If the repository is
152 published for dumb transports, this file should be
153 - regenerated by `git-update-server-info` every time a tag
153 + regenerated by 'git-update-server-info' every time a tag
154 or branch is created or modified. This is normally done
155 from the `hooks/update` hook, which is run by the
156 - `git-receive-pack` command when you `git-push` into the
156 + 'git-receive-pack' command when you 'git-push' into the
157 repository.
158
159 info/grafts::
@@ -167,14 +167,14 @@ info/grafts::
167 info/exclude::
168 This file, by convention among Porcelains, stores the
169 exclude pattern list. `.gitignore` is the per-directory
170 - ignore file. `git-status`, `git-add`, `git-rm` and
171 - `git-clean` look at it but the core git commands do not look
170 + ignore file. 'git-status', 'git-add', 'git-rm' and
171 + 'git-clean' look at it but the core git commands do not look
172 at it. See also: linkgit:gitignore[5].
173
174 remotes::
175 Stores shorthands to be used to give URL and default
176 refnames to interact with remote repository to
177 - `git-fetch`, `git-pull` and `git-push` commands.
177 + 'git-fetch', 'git-pull' and 'git-push' commands.
178
179 logs::
180 Records of changes made to refs are stored in this
Documentation/gittutorial-2.txt
+8 -8
@@ -255,7 +255,7 @@ index a042389..513feba 100644
255 +hello world, again
256 ------------------------------------------------
257
258 -So `git-diff` is comparing against something other than the head.
258 +So 'git-diff' is comparing against something other than the head.
259 The thing that it's comparing against is actually the index file,
260 which is stored in .git/index in a binary format, but whose contents
261 we can examine with ls-files:
@@ -270,9 +270,9 @@ hello world!
270 hello world, again
271 ------------------------------------------------
272
273 -So what our `git-add` did was store a new blob and then put
273 +So what our 'git-add' did was store a new blob and then put
274 a reference to it in the index file. If we modify the file again,
275 -we'll see that the new modifications are reflected in the `git-diff`
275 +we'll see that the new modifications are reflected in the 'git-diff'
276 output:
277
278 ------------------------------------------------
@@ -287,7 +287,7 @@ index 513feba..ba3da7b 100644
287 +again?
288 ------------------------------------------------
289
290 -With the right arguments, `git-diff` can also show us the difference
290 +With the right arguments, 'git-diff' can also show us the difference
291 between the working directory and the last commit, or between the
292 index and the last commit:
293
@@ -311,7 +311,7 @@ index a042389..513feba 100644
311 +hello world, again
312 ------------------------------------------------
313
314 -At any time, we can create a new commit using `git-commit` (without
314 +At any time, we can create a new commit using 'git-commit' (without
315 the "-a" option), and verify that the state committed only includes the
316 changes stored in the index file, not the additional change that is
317 still only in our working tree:
@@ -329,11 +329,11 @@ index 513feba..ba3da7b 100644
329 +again?
330 ------------------------------------------------
331
332 -So by default `git-commit` uses the index to create the commit, not
332 +So by default 'git-commit' uses the index to create the commit, not
333 the working tree; the "-a" option to commit tells it to first update
334 the index with all changes in the working tree.
335
336 -Finally, it's worth looking at the effect of `git-add` on the index
336 +Finally, it's worth looking at the effect of 'git-add' on the index
337 file:
338
339 ------------------------------------------------
@@ -341,7 +341,7 @@ $ echo "goodbye, world" >closing.txt
341 $ git add closing.txt
342 ------------------------------------------------
343
344 -The effect of the `git-add` was to add one entry to the index file:
344 +The effect of the 'git-add' was to add one entry to the index file:
345
346 ------------------------------------------------
347 $ git ls-files --stage
Documentation/gittutorial.txt
+21 -21
@@ -58,7 +58,7 @@ You've now initialized the working directory--you may notice a new
58 directory created, named ".git".
59
60 Next, tell git to take a snapshot of the contents of all files under the
61 -current directory (note the '.'), with `git-add`:
61 +current directory (note the '.'), with 'git-add':
62
63 ------------------------------------------------
64 $ git add .
@@ -66,7 +66,7 @@ $ git add .
66
67 This snapshot is now stored in a temporary staging area which git calls
68 the "index". You can permanently store the contents of the index in the
69 -repository with `git-commit`:
69 +repository with 'git-commit':
70
71 ------------------------------------------------
72 $ git commit
@@ -85,15 +85,15 @@ $ git add file1 file2 file3
85 ------------------------------------------------
86
87 You are now ready to commit. You can see what is about to be committed
88 -using `git-diff` with the --cached option:
88 +using 'git-diff' with the --cached option:
89
90 ------------------------------------------------
91 $ git diff --cached
92 ------------------------------------------------
93
94 -(Without --cached, `git-diff` will show you any changes that
94 +(Without --cached, 'git-diff' will show you any changes that
95 you've made but not yet added to the index.) You can also get a brief
96 -summary of the situation with `git-status`:
96 +summary of the situation with 'git-status':
97
98 ------------------------------------------------
99 $ git status
@@ -117,7 +117,7 @@ $ git commit
117 This will again prompt you for a message describing the change, and then
118 record a new version of the project.
119
120 -Alternatively, instead of running `git-add` beforehand, you can use
120 +Alternatively, instead of running 'git-add' beforehand, you can use
121
122 ------------------------------------------------
123 $ git commit -a
@@ -138,7 +138,7 @@ Git tracks content not files
138
139 Many revision control systems provide an `add` command that tells the
140 system to start tracking changes to a new file. Git's `add` command
141 -does something simpler and more powerful: `git-add` is used both for new
141 +does something simpler and more powerful: 'git-add' is used both for new
142 and newly modified files, and in both cases it takes a snapshot of the
143 given files and stages that content in the index, ready for inclusion in
144 the next commit.
@@ -316,7 +316,7 @@ $ git remote add bob /home/bob/myrepo
316 ------------------------------------------------
317
318 With this, Alice can perform the first operation alone using the
319 -`git-fetch` command without merging them with her own branch,
319 +'git-fetch' command without merging them with her own branch,
320 using:
321
322 -------------------------------------
@@ -324,7 +324,7 @@ $ git fetch bob
324 -------------------------------------
325
326 Unlike the longhand form, when Alice fetches from Bob using a
327 -remote repository shorthand set up with `git-remote`, what was
327 +remote repository shorthand set up with 'git-remote', what was
328 fetched is stored in a remote tracking branch, in this case
329 `bob/master`. So after this:
330
@@ -368,7 +368,7 @@ $ git config --get remote.origin.url
368 /home/alice/project
369 -------------------------------------
370
371 -(The complete configuration created by `git-clone` is visible using
371 +(The complete configuration created by 'git-clone' is visible using
372 `git config -l`, and the linkgit:git-config[1] man page
373 explains the meaning of each option.)
374
@@ -398,7 +398,7 @@ Exploring history
398 -----------------
399
400 Git history is represented as a series of interrelated commits. We
401 -have already seen that the `git-log` command can list those commits.
401 +have already seen that the 'git-log' command can list those commits.
402 Note that first line of each git log entry also gives a name for the
403 commit:
404
@@ -411,7 +411,7 @@ Date: Tue May 16 17:18:22 2006 -0700
411 merge-base: Clarify the comments on post processing.
412 -------------------------------------
413
414 -We can give this name to `git-show` to see the details about this
414 +We can give this name to 'git-show' to see the details about this
415 commit.
416
417 -------------------------------------
@@ -469,13 +469,13 @@ $ git reset --hard HEAD^ # reset your current branch and working
469 Be careful with that last command: in addition to losing any changes
470 in the working directory, it will also remove all later commits from
471 this branch. If this branch is the only branch containing those
472 -commits, they will be lost. Also, don't use `git-reset` on a
472 +commits, they will be lost. Also, don't use 'git-reset' on a
473 publicly-visible branch that other developers pull from, as it will
474 force needless merges on other developers to clean up the history.
475 -If you need to undo changes that you have pushed, use `git-revert`
475 +If you need to undo changes that you have pushed, use 'git-revert'
476 instead.
477
478 -The `git-grep` command can search for strings in any version of your
478 +The 'git-grep' command can search for strings in any version of your
479 project, so
480
481 -------------------------------------
@@ -484,7 +484,7 @@ $ git grep "hello" v2.5
484
485 searches for all occurrences of "hello" in v2.5.
486
487 -If you leave out the commit name, `git-grep` will search any of the
487 +If you leave out the commit name, 'git-grep' will search any of the
488 files it manages in your current directory. So
489
490 -------------------------------------
@@ -494,7 +494,7 @@ $ git grep "hello"
494 is a quick way to search just the files that are tracked by git.
495
496 Many git commands also take sets of commits, which can be specified
497 -in a number of ways. Here are some examples with `git-log`:
497 +in a number of ways. Here are some examples with 'git-log':
498
499 -------------------------------------
500 $ git log v2.5..v2.6 # commits between v2.5 and v2.6
@@ -504,7 +504,7 @@ $ git log v2.5.. Makefile # commits since v2.5 which modify
504 # Makefile
505 -------------------------------------
506
507 -You can also give `git-log` a "range" of commits where the first is not
507 +You can also give 'git-log' a "range" of commits where the first is not
508 necessarily an ancestor of the second; for example, if the tips of
509 the branches "stable-release" and "master" diverged from a common
510 commit some time ago, then
@@ -523,9 +523,9 @@ $ git log experimental..stable
523 will show the list of commits made on the stable branch but not
524 the experimental branch.
525
526 -The `git-log` command has a weakness: it must present commits in a
526 +The 'git-log' command has a weakness: it must present commits in a
527 list. When the history has lines of development that diverged and
528 -then merged back together, the order in which `git-log` presents
528 +then merged back together, the order in which 'git-log' presents
529 those commits is meaningless.
530
531 Most projects with multiple contributors (such as the linux kernel,
@@ -549,7 +549,7 @@ of the file:
549 $ git diff v2.5:Makefile HEAD:Makefile.in
550 -------------------------------------
551
552 -You can also use `git-show` to see any such file:
552 +You can also use 'git-show' to see any such file:
553
554 -------------------------------------
555 $ git show v2.5:Makefile
Documentation/i18n.txt
+2 -2
@@ -21,7 +21,7 @@ project find it more convenient to use legacy encodings, git
21 does not forbid it. However, there are a few things to keep in
22 mind.
23
24 -. `git-commit-tree` (hence, `git-commit` which uses it) issues
24 +. 'git-commit-tree' (hence, 'git-commit' which uses it) issues
25 a warning if the commit log message given to it does not look
26 like a valid UTF-8 string, unless you explicitly say your
27 project uses a legacy encoding. The way to say this is to
@@ -37,7 +37,7 @@ of `i18n.commitencoding` in its `encoding` header. This is to
37 help other people who look at them later. Lack of this header
38 implies that the commit log message is encoded in UTF-8.
39
40 -. `git-log`, `git-show` and friends looks at the `encoding`
40 +. 'git-log', 'git-show' and friends looks at the `encoding`
41 header of a commit object, and tries to re-code the log
42 message into UTF-8 unless otherwise specified. You can
43 specify the desired output encoding with
Documentation/merge-options.txt
+2 -2
@@ -56,5 +56,5 @@
56 Use the given merge strategy; can be supplied more than
57 once to specify them in the order they should be tried.
58 If there is no `-s` option, a built-in list of strategies
59 - is used instead (`git-merge-recursive` when merging a single
60 - head, `git-merge-octopus` otherwise).
59 + is used instead ('git-merge-recursive' when merging a single
60 + head, 'git-merge-octopus' otherwise).
Documentation/pull-fetch-param.txt
+4 -4
@@ -32,7 +32,7 @@ must know this is the expected usage pattern for a branch.
32 [NOTE]
33 You never do your own development on branches that appear
34 on the right hand side of a <refspec> colon on `Pull:` lines;
35 -they are to be updated by `git-fetch`. If you intend to do
35 +they are to be updated by 'git-fetch'. If you intend to do
36 development derived from a remote branch `B`, have a `Pull:`
37 line to track it (i.e. `Pull: B:remote-B`), and have a separate
38 branch `my-B` to do your development on top of it. The latter
@@ -44,13 +44,13 @@ on the remote branch, merge it into your development branch with
44 +
45 [NOTE]
46 There is a difference between listing multiple <refspec>
47 -directly on `git-pull` command line and having multiple
47 +directly on 'git-pull' command line and having multiple
48 `Pull:` <refspec> lines for a <repository> and running
49 -`git-pull` command without any explicit <refspec> parameters.
49 +'git-pull' command without any explicit <refspec> parameters.
50 <refspec> listed explicitly on the command line are always
51 merged into the current branch after fetching. In other words,
52 if you list more than one remote refs, you would be making
53 -an Octopus. While `git-pull` run without any explicit <refspec>
53 +an Octopus. While 'git-pull' run without any explicit <refspec>
54 parameter takes default <refspec>s from `Pull:` lines, it
55 merges only the first <refspec> found into the current branch,
56 after fetching all the remote refs. This is because making an
Documentation/urls-remotes.txt
+2 -2
@@ -49,8 +49,8 @@ following format:
49
50 ------------
51
52 -`Push:` lines are used by `git-push` and
53 -`Pull:` lines are used by `git-pull` and `git-fetch`.
52 +`Push:` lines are used by 'git-push' and
53 +`Pull:` lines are used by 'git-pull' and 'git-fetch'.
54 Multiple `Push:` and `Pull:` lines may
55 be specified for additional branch mappings.
56