483bc4f045 · matheusbsbs/matheus-bagliano

Documentation/git-annotate.txt

+1 -1

@@ -7,7 +7,7 @@ git-annotate - Annotate file lines with commit info

7

8 SYNOPSIS

9 --------

10 -git annotate [options] file [revision]

10 +'git annotate' [options] file [revision]

11

12 DESCRIPTION

13 -----------

Documentation/git-apply.txt

+6 -6

@@ -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, linkgit:git-apply[1] 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, linkgit:git-apply[1] 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, linkgit:git-apply[1] 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.

@@ -147,7 +147,7 @@ discouraged.

147 considered whitespace errors.

148 +

149 By default, the command outputs warning messages but applies the patch.

150 -When linkgit:git-apply[1] is used for statistics and not applying a

150 +When `git-apply is used for statistics and not applying a

151 patch, it defaults to `nowarn`.

152 +

153 You can use different `<action>` to control this

@@ -191,7 +191,7 @@ apply.whitespace::

191

192 Submodules

193 ----------

194 -If the patch contains any changes to submodules then linkgit:git-apply[1]

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

+3 -3

@@ -34,12 +34,12 @@ 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`.

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

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 executable 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

+4 -4

@@ -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' option 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

@@ -215,13 +215,13 @@ 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

222 tree to the pristine state. Finally the "run" script can exit with

223 -the status of the real test to let "git bisect run" command loop to

224 -know the outcome.

223 +the status of the real test to let the "git bisect run" command loop to

224 +determine the outcome.

225

226 EXAMPLES

227 --------

Documentation/git-blame.txt

+2 -2

@@ -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 linkgit:git-diff[1] 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::

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 linkgit:git-pull[1] 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 linkgit:git-fetch[1] 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 -14

@@ -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 linkgit:git-fetch[1] and linkgit:git-pull[1]

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,16 +51,15 @@ list-heads <file>::

51 printed out.

52

53 unbundle <file>::

54 - Passes the objects in the bundle to linkgit:git-index-pack[1]

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

59 - linkgit:git-fetch[1].

58 + really plumbing, intended to be called only by `git-fetch`.

59

60 [git-rev-list-args...]::

62 - A list of arguments, acceptable to git-rev-parse and

63 - 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

@@ -70,16 +69,16 @@ unbundle <file>::

69

70 [refname...]::

71 A list of references used to limit the references reported as

73 - 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

75 - necessarily everything in the pack (in this case, git-bundle is

76 - acting like linkgit:git-fetch-pack[1]).

74 + necessarily everything in the pack (in this case, `git-bundle` is

75 + acting like `git-fetch-pack`).

76

77 SPECIFYING REFERENCES

78 ---------------------

79

81 -git-bundle will only package references that are shown by

82 -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 - linkgit:git-cat-file[1] "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

+1 -1

@@ -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

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

@@ -19,7 +19,7 @@ OPTIONS

19 -------

20 <commit>::

21 Commit to cherry-pick.

22 - For a more complete list of ways to spell commits, see

22 + For a more complete list of ways to spell commits, see the

23 "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].

24

25 -e::

Documentation/git-cherry.txt

+4 -4

@@ -13,8 +13,8 @@ DESCRIPTION

13 -----------

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 linkgit:git-patch-id[1]

17 -program.

16 +The commits are compared with their 'patch id', obtained from

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 linkgit:git-commit[1] 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 linkgit:git-reset[1]) 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

+6 -6

@@ -68,10 +68,10 @@ 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[1])

72 -which automatically call git-gc[1]. If these objects are removed and

73 -were referenced by the cloned repository, then the cloned repository

74 -will become corrupt.

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.

75

76

77

@@ -88,7 +88,7 @@ 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 @@ 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 @@ commit along with a log message describing the changes you have made.

20

21 The content to be added can be specified in several ways:

22

23 -1. by using linkgit:git-add[1] 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 linkgit:git-rm[1] 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

@@ -41,13 +41,13 @@ The content to be added can be specified in several ways:

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`.

43

44 -The linkgit:git-status[1] 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 found a mistake immediately after

50 -that, you can recover from it with linkgit:git-reset[1].

49 +If you make a commit and then find a mistake immediately after

50 +that, you can recover from it with `git-reset`.

51

52

53 OPTIONS

@@ -205,7 +205,7 @@ 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 linkgit:git-add[1]. 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

@@ -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 either linkgit:git-merge[1] or

268 -linkgit:git-pull[1]) stops because of conflicts, cleanly merged

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 linkgit:git-status[1]

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 linkgit:git-add[1]:

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

+4 -3

@@ -8,7 +8,8 @@ git-cvsexportcommit - Export a single commit to a CVS checkout

8

9 SYNOPSIS

10 --------

11 -'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID

11 +'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot]

12 + [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID

13

14

15 DESCRIPTION

@@ -26,8 +27,8 @@ by default.

27

28 Supports file additions, removals, and commits that affect binary files.

29

29 -If the commit is a merge commit, you must tell git-cvsexportcommit what parent

30 -should the changeset be done against.

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

34 -------

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 -linkgit:git-cvsexportcommit[1].

149 +`git-cvsexportcommit`.

150

151 -h::

152 Print a short usage message and exit.

Documentation/git-cvsserver.txt

+21 -22

@@ -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 @@ git-cvsserver and pretends that the other end runs the real cvs better.

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

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

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 ---------------------

@@ -328,14 +328,13 @@ is left blank. But if `gitcvs.allbinary` is set to "guess", then

328 the correct '-k' mode will be guessed based on the contents of

329 the file.

330

331 -For best consistency with cvs, it is probably best to override the

331 +For best consistency with `cvs`, it is probably best to override the

332 defaults by setting `gitcvs.usecrlfattr` to true,

333 and `gitcvs.allbinary` to "guess".

334

335 Dependencies

336 ------------

337 -

338 -git-cvsserver depends on DBD::SQLite.

337 +`git-cvsserver` depends on DBD::SQLite.

338

339 Copyright and Authors

340 ---------------------

Documentation/git-daemon.txt

+11 -11

@@ -9,11 +9,11 @@ SYNOPSIS

9 --------

10 [verse]

11 'git daemon' [--verbose] [--syslog] [--export-all]

12 - [--timeout=n] [--init-timeout=n] [--strict-paths]

13 - [--base-path=path] [--user-path | --user-path=path]

14 - [--interpolated-path=pathtemplate]

15 - [--reuseaddr] [--detach] [--pid-file=file]

16 - [--enable=service] [--disable=service]

12 + [--timeout=n] [--init-timeout=n] [--strict-paths]

13 + [--base-path=path] [--user-path | --user-path=path]

14 + [--interpolated-path=pathtemplate]

15 + [--reuseaddr] [--detach] [--pid-file=file]

16 + [--enable=service] [--disable=service]

17 [--allow-override=service] [--forbid-override=service]

18 [--inetd | [--listen=host_or_ipaddr] [--port=n] [--user=user [--group=group]]

19 [directory...]

@@ -27,7 +27,7 @@ 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

@@ -44,12 +44,12 @@ OPTIONS

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

55 as '/srv/git/hello.git'.

@@ -199,7 +199,7 @@ $ grep 9418 /etc/services

199 git 9418/tcp # Git Version Control System

200 ------------

201

202 -git-daemon as inetd server::

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

@@ -212,7 +212,7 @@ git-daemon as inetd server::

212 ------------------------------------------------

213

214

215 -git-daemon as inetd server for virtual hosts::

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

@@ -235,7 +235,7 @@ 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::

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:

Documentation/git-describe.txt

+4 -4

@@ -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.

@@ -129,7 +129,7 @@ abbreviation of the input committish's SHA1.

129 If multiple tags were found during the walk then the tag which

130 has the fewest commits different from the input committish will be

131 selected and output. Here fewest commits different is defined as

132 -the number of commits which would be shown by "git log tag..input"

132 +the number of commits which would be shown by `git log tag..input`

133 will be the smallest number of commits possible.

134

135

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 "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

+13 -13

@@ -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 with a "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

@@ -60,9 +60,9 @@ object and compare it that way, and to do that, you just do

60 git diff-index --cached HEAD

61

62 Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had

63 -done an "git-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:

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:

66

67 torvalds@ppc970:~/git> git diff-index --cached HEAD

68 -100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c

@@ -70,11 +70,11 @@ matches my working directory. But doing a "git-diff-index" does:

70

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

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

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 linkgit:git-fast-import[1].

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 -linkgit:git-filter-branch[1].

20 +`git-filter-branch`.

21

22

23 OPTIONS

24 -------

25 --progress=<n>::

26 Insert 'progress' statements every <n> objects, to be shown by

27 - linkgit:git-fast-import[1] 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 linkgit:git-fast-import[1] 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

+8 -8

@@ -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 linkgit:git-init[1]) 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 linkgit:git-pack-objects[1].

85 + to `git-pack-objects`.

86

87 --quiet::

88 Disable all non-fatal output, making fast-import silent when it

@@ -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 linkgit:git-am[1] 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 -linkgit:git-update-index[1].

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 linkgit:git-tag[1] 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 linkgit:git-blame[1] 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 linkgit:git-repack[1].

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

+8 -8

@@ -12,14 +12,14 @@ SYNOPSIS

12

13 DESCRIPTION

14 -----------

15 -Usually you would want to use linkgit:git-fetch[1] which is a

16 -higher level wrapper of this command instead.

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 potentially 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

+6 -6

@@ -95,7 +95,7 @@ OPTIONS

95 This is the filter for rewriting the commit's parent list.

96 It will receive the parent string on stdin and shall output

97 the new parent string on stdout. The parent string is in

98 - a format accepted by linkgit:git-commit-tree[1]: empty for

98 + the format described in linkgit:git-commit-tree[1]: empty for

99 the initial commit, "-p parent" for a normal commit and

100 "-p parent1 -p parent2 -p parent3 ..." for a merge commit.

101

@@ -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 - linkgit:git-commit-tree[1] 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 linkgit:git-rebase[1] instead).

122 +that, use `git-rebase` instead).

123

124 --tag-name-filter <command>::

125 This is the filter for rewriting tag names. When passed,

@@ -169,7 +169,7 @@ to other tags will be rewritten to point to the underlying commit.

169

170 <rev-list-options>::

171 When options are given after the new branch name, they will

172 - be passed to linkgit:git-rev-list[1]. 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

@@ -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 linkgit:git-rebase[1].

275 +interactive mode of `git-rebase`.

276

277

278 Consider this history:

Documentation/git-fmt-merge-msg.txt

+2 -2

@@ -9,8 +9,8 @@ git-fmt-merge-msg - Produce a merge commit message

9 SYNOPSIS

10 --------

11 [verse]

12 -git fmt-merge-msg [--log | --no-log] <$GIT_DIR/FETCH_HEAD

13 -git fmt-merge-msg [--log | --no-log] -F <file>

12 +'git fmt-merge-msg' [--log | --no-log] <$GIT_DIR/FETCH_HEAD

13 +'git fmt-merge-msg' [--log | --no-log] -F <file>

14

15 DESCRIPTION

16 -----------

Documentation/git-format-patch.txt

+2 -2

@@ -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 linkgit:git-am[1].

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.

Documentation/git-fsck.txt

+3 -3

@@ -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,11 +83,11 @@ 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

90 -(i.e., you can just remove them and do an "rsync" with some other site in

90 +(i.e., you can just remove them and do an `rsync` with some other site in

91 the hopes that somebody else has the object you have corrupted).

92

93 Of course, "valid tree" doesn't mean that it wasn't generated by some

Documentation/git-gc.txt

+5 -5

@@ -15,7 +15,7 @@ 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 linkgit:git-add[1].

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

@@ -33,9 +33,9 @@ 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.

@@ -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 linkgit:git-filter-branch[1] 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 -linkgit:git-archive[1]. 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

+12 -12

@@ -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 linkgit:gitk[1], 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.

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`.

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 - linkgit:git-repack[1].

46 + `git-repack`.

47

48 --fix-thin::

49 - It is possible for linkgit:git-pack-objects[1] 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 linkgit:git-repack[1] 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 linkgit:git-repack[1]

89 +.keep file used as a lock to prevent the race with `git-repack`

90 mentioned above.

91

92

Documentation/git-instaweb.txt

+2 -2

@@ -14,7 +14,7 @@ SYNOPSIS

14

15 DESCRIPTION

16 -----------

17 -A simple script to setup gitweb and a web server for browsing the local

17 +A simple script to set up `gitweb` and a web server for browsing the local

18 repository.

19

20 OPTIONS

@@ -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 linkgit:git-rev-list[1]

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 linkgit:git-diff-tree[1] 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

+4 -4

@@ -143,14 +143,14 @@ 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,

150 the index records up to three such pairs; one from tree O in stage

151 1, A in stage 2, and B in stage 3. This information can be used by

152 the user (or the porcelain) to see what should eventually be recorded at the

153 -path. (see git-read-tree for more information on state)

153 +path. (see linkgit:git-read-tree[1] for more information on state)

154

155 When `-z` option is not used, TAB, LF, and backslash characters

156 in pathnames are represented as `\t`, `\n`, and `\\`,

@@ -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 linkgit:git-upload-pack[1] 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

+4 -4

@@ -13,15 +13,15 @@ SYNOPSIS

13 DESCRIPTION

14 -----------

15

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

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.

20

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

+7 -7

@@ -36,20 +36,20 @@ 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

50 -RCS "merge" program merge object order. In the above ordering, the

50 +RCS `merge` program merge object order. In the above ordering, the

51 original is first. But the argument order to the 3-way merge program

52 -"merge" is to have the original in the middle. Don't ask me why.

52 +`merge` is to have the original in the middle. Don't ask me why.

53

54 Examples:

55

@@ -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

72 -merge once anything has returned an error (i.e., "cat" returned an error

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 -6

@@ -41,8 +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

45 -linkgit:git-reset[1].

44 +would want to start over, you can recover with `git-reset`.

45

46 CONFIGURATION

47 -------------

@@ -50,7 +49,7 @@ include::merge-config.txt[]

49

50 branch.<name>.mergeoptions::

51 Sets default options for merging into branch <name>. The syntax and

53 - 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

@@ -145,7 +144,7 @@ After seeing a conflict, you can do two things:

144 be used for this.

145

146 * Resolve the conflicts. `git diff` would report only the

148 - conflicting paths because of the above 2. and 3.. Edit 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`

149 them, to make the index file contain what the merge result

150 should be, and run `git-commit` to commit the result.

@@ -154,8 +153,11 @@ After seeing a conflict, you can do two things:

153 SEE ALSO

154 --------

155 linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],

157 -linkgit:gitattributes[5]

158 -

156 +linkgit:gitattributes[5],

157 +linkgit:git-reset[1],

158 +linkgit:git-diff[1], linkgit:git-ls-files[1],

159 +linkgit:git-add[1], linkgit:git-rm[1],

160 +linkgit:git-mergetool[1]

161

162 Author

163 ------

Documentation/git-mergetool.txt

+1 -1

@@ -13,7 +13,7 @@ DESCRIPTION

13 -----------

14

15 Use `git mergetool` to run one of several merge utilities to resolve

16 -merge conflicts. It is typically run after linkgit:git-merge[1].

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

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 linkgit:git-describe[1] 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

+4 -4

@@ -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 -'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 linkgit:git-rev-list[1] with `--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

@@ -163,14 +163,14 @@ base-name::

163 generated pack. If not specified, pack compression level is

164 determined first by pack.compression, then by core.compression,

165 and defaults to -1, the zlib default, if neither is set.

166 - Add \--no-reuse-object if you want to force a uniform compression

166 + Add --no-reuse-object if you want to force a uniform compression

167 level on all data no matter the source.

168

169 --delta-base-offset::

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

+2 -2

@@ -14,9 +14,9 @@ DESCRIPTION

14 -----------

15 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.

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-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

+2 -2

@@ -17,7 +17,7 @@ This command is deprecated; use `git-ls-remote` instead.

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

+5 -5

@@ -13,8 +13,8 @@ SYNOPSIS

13 DESCRIPTION

14 -----------

15

16 -NOTE: In most cases, users should run linkgit:git-gc[1], 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

20 available in `$GIT_DIR/refs`, optionally with additional set of

@@ -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 linkgit:git-gc[1], 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

+1 -2

@@ -182,8 +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

186 -linkgit:git-reset[1].

185 +would want to start over, you can recover with `git-reset`.

186

187

188 SEE ALSO

Documentation/git-push.txt

+1 -1

@@ -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.

Documentation/git-read-tree.txt

+7 -7

@@ -121,7 +121,7 @@ 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

@@ -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

@@ -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

@@ -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,7 +334,7 @@ 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

Documentation/git-rebase.txt

+11 -11

@@ -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

@@ -364,34 +364,34 @@ 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

371 -- Start an interactive rebase with 'git rebase -i <commit>^', where

371 +- Start an interactive rebase with `git rebase -i <commit>^`, where

372 <commit> is the commit you want to split. In fact, any commit range

373 will do, as long as it contains that commit.

374

375 - Mark the commit you want to split with the action "edit".

376

377 -- When it comes to editing that commit, execute 'git reset HEAD^'. The

377 +- When it comes to editing that commit, execute `git reset HEAD^`. The

378 effect is that the HEAD is rewound by one, and the index follows suit.

379 However, the working tree stays the same.

380

381 - Now add the changes to the index that you want to have in the first

382 - commit. You can use linkgit:git-add[1] (possibly interactively) and/or

383 - linkgit:git-gui[1] to do that.

382 + commit. You can use `git add` (possibly interactively) or

383 + `git-gui` (or both) to do that.

384

385 - Commit the now-current index with whatever commit message is appropriate

386 now.

387

388 - Repeat the last two steps until your working tree is clean.

389

390 -- Continue the rebase with 'git rebase --continue'.

390 +- Continue the rebase with `git rebase --continue`.

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 -linkgit:git-stash[1] 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

+8 -8

@@ -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 'git-fetch-pack'.

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 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 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,10 +137,10 @@ 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"

143 +This hook can be used, for example, to run `git update-server-info`

144 if the repository is packed and is served via a dumb transport.

145

146 #!/bin/sh

Documentation/git-repack.txt

+6 -5

@@ -47,23 +47,24 @@ 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 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 runs linkgit:git-prune-packed[1].

55 + Also run `git-prune-packed` to remove redundant

56 + loose object files.

57

58 -l::

58 - 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::

62 - 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::

66 - 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::

Documentation/git-rerere.txt

+5 -5

@@ -30,22 +30,22 @@ 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 linkgit:git-am[1] --skip or linkgit:git-rebase[1]

41 -[--skip|--abort] will automatically invoke this command.

40 +is aborted. Calling `git-am --skip` or `git-rebase [--skip|--abort]`

41 +will automatically invoke this command.

42

43 'diff'::

44

45 This displays diffs for the current state of the resolution. It is

46 useful for tracking what has changed while the user is resolving

47 conflicts. Additional arguments are passed directly to the system

48 -diff(1) command installed in PATH.

48 +`diff` command installed in PATH.

49

50 'status'::

51

@@ -146,7 +146,7 @@ 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 `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,

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 linkgit:git-status[1] 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 -linkgit:git-rev-list[1] 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 linkgit:git-bisect[1] and

90 -linkgit:git-repack[1].

89 +used by commands as different as `git-bisect` and

90 +`git-repack`.

91

92 OPTIONS

93 -------

Documentation/git-rev-parse.txt

+6 -6

@@ -15,8 +15,8 @@ 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 underlying `git-rev-list` command they use internally

19 -and flags and parameters for other commands they use as the

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

21 distinguish between them.

22

@@ -128,13 +128,13 @@ OPTIONS

128

129 --since=datestring::

130 --after=datestring::

131 - Parses the date string, and outputs corresponding

132 - --max-age= parameter for git-rev-list command.

131 + Parse the date string, and output the corresponding

132 + --max-age= parameter for `git-rev-list`.

133

134 --until=datestring::

135 --before=datestring::

136 - Parses the date string, and outputs corresponding

137 - --min-age= parameter for git-rev-list command.

136 + Parse the date string, and output the corresponding

137 + --min-age= parameter for `git-rev-list`.

138

139 <args>...::

140 Flags and parameters to be parsed.

Documentation/git-rm.txt

+1 -1

@@ -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

+7 -7

@@ -12,17 +12,17 @@ SYNOPSIS

12

13 DESCRIPTION

14 -----------

15 -Usually you would want to use linkgit:git-push[1] which is a

16 -higher level wrapper of this command instead.

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,8 +86,8 @@ 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 linkgit:git-rev-parse[1] to resolve a symbolic ref

90 -name.

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

93 local refs.

Documentation/git-shell.txt

+1 -1

@@ -8,7 +8,7 @@ git-shell - Restricted login shell for GIT-only SSH access

8

9 SYNOPSIS

10 --------

11 -'git-shell' -c <command> <argument>

11 +'$(git --exec-path)/git-shell' -c <command> <argument>

12

13 DESCRIPTION

14 -----------

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

+2 -2

@@ -29,7 +29,7 @@ no <rev> nor <glob> is given on the command line.

29 OPTIONS

30 -------

31 <rev>::

32 - Arbitrary extended SHA1 expression (see `git-rev-parse`)

32 + Arbitrary extended SHA1 expression (see linkgit:git-rev-parse[1])

33 that typically names a branch HEAD or a tag.

34

35 <glob>::

@@ -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, linkgit:git-show-ref[1] 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 linkgit:git-ls-tree[1]

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 linkgit:git-diff-tree[1] 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

+6 -6

@@ -20,10 +20,10 @@ working directory. The command saves your local modifications away

20 and reverts the working directory to match the `HEAD` commit.

21

22 The modifications stashed away by this command can be listed with

23 -`git-stash list`, inspected with `git-stash show`, and restored

24 -(potentially on top of a different commit) with `git-stash apply`.

25 -Calling git stash without any arguments is equivalent to `git stash

26 -save`. A stash is by default listed as "WIP on 'branchname' ...", but

23 +`git stash list`, inspected with `git stash show`, and restored

24 +(potentially on top of a different commit) with `git stash apply`.

25 +Calling `git stash` without any arguments is equivalent to `git stash save`.

26 +A stash is by default listed as "WIP on 'branchname' ...", but

27 you can give a more descriptive message on the command line when

28 you create one.

29

@@ -56,8 +56,8 @@ 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 linkgit:git-log[1]

60 -command to control what is shown and how.

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>]::

63

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 linkgit:git-describe[1] 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

+66 -67

@@ -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'

115 -accepts. However '--fetch-all' only fetches from the current

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

223 - init-ed repository. This command takes three arguments, (a) the

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 linkgit:git-init[1].

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 linkgit:git-repack[1].

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::

@@ -411,20 +411,20 @@ CONFIG FILE-ONLY OPTIONS

411 svn.noMetadata::

412 svn-remote.<name>.noMetadata::

413

414 -This gets rid of the git-svn-id: lines at the end of every commit.

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,22 +524,22 @@ 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.

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.

531

532 -If you use 'git svn set-tree A..B' to commit several diffs and you do

532 +If you use `git svn set-tree A..B` to commit several diffs and you do

533 not have the latest remotes/git-svn merged into my-branch, you should

534 -use 'git svn rebase' to update your work branch instead of 'git pull' or

535 -'git merge'. 'pull/merge' can cause non-linear history to be flattened

534 +use `git svn rebase` to update your work branch instead of `git pull` or

535 +`git merge`. `pull`/`merge' can cause non-linear history to be flattened

536 when committing into SVN, which can lead to merge commits reversing

537 previous commits in SVN.

538

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,30 +550,30 @@ 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 dcommiting 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

560 -plan to dcommit from. Subversion does not represent merges in any

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

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(1) 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

572 -before dcommit on will require forcing an overwrite of the existing ref

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 git-push(1) documentation for details.

574 +see the linkgit:git-push[1] documentation for details.

575

576 -Do not use the --amend option of git-commit(1) on a change you've

576 +Do not use the --amend option of linkgit:git-commit[1] on a change you've

577 already dcommitted. It is considered bad practice to --amend commits

578 you've already pushed to a remote repository for other users, and

579 dcommit with SVN is analogous to that.

@@ -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,8 +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

619 -linkgit:git-config[1]

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 "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

+2 -2

@@ -19,12 +19,12 @@ 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-unpack-objects.txt

+1 -1

@@ -21,7 +21,7 @@ Objects that already exist in the repository will *not* be unpacked

21 from the pack-file. Therefore, nothing will be unpacked if you use

22 this command on a pack-file that exists within the target repository.

23

24 -Please see the `git-repack` documentation for options to generate

24 +See linkgit:git-repack[1] for options to generate

25 new packs and replace existing ones.

26

27 OPTIONS

Documentation/git-update-index.txt

+7 -7

@@ -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::

@@ -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

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-verify-pack.txt

+2 -2

@@ -13,8 +13,8 @@ SYNOPSIS

13

14 DESCRIPTION

15 -----------

16 -Reads given idx file for packed git archive created with

17 -git-pack-objects command and verifies idx file and the

16 +Reads given idx file for packed git archive created with 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.txt

+5 -5

@@ -483,10 +483,10 @@ other

483 a pager.

484

485 'GIT_SSH'::

486 - If this environment variable is set then linkgit:git-fetch[1]

487 - and linkgit:git-push[1] will use this command instead

486 + If this environment variable is set then `git-fetch`

487 + and `git-push` will use this command instead

488 of `ssh` when they need to connect to a remote system.

489 - The 'GIT_SSH' command will be given exactly two arguments:

489 + The '$GIT_SSH' command will be given exactly two arguments:

490 the 'username@host' (or just 'host') from the URL and the

491 shell command to execute on that remote system.

492 +

@@ -500,8 +500,8 @@ for further details.

500

501 'GIT_FLUSH'::

502 If this environment variable is set to "1", then commands such

503 - as git-blame (in incremental mode), git-rev-list, git-log,

504 - git-whatchanged, etc., will force a flush of the output stream

503 + as `git-blame` (in incremental mode), `git-rev-list`, `git-log`,

504 + and `git-whatchanged` will force a flush of the output stream

505 after each commit-oriented record have been flushed. If this

506 variable is set to "0", the output of these commands will be done

507 using completely buffered I/O. If this environment variable is

Documentation/gitattributes.txt

+6 -6

@@ -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

@@ -513,8 +513,8 @@ archive files.

513

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 -linkgit:git-archive[1] has been given a tree instead of a commit or a

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

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

+9 -9

@@ -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 ------------

@@ -284,7 +284,7 @@ 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`.

287 -There are no options or other input: git write-tree will take the

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

290 filenames with their contents (and their permissions), and we're

@@ -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

@@ -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

@@ -963,18 +963,18 @@ commits from the master branch. The string inside brackets

963 before the commit log message is a short name you can use to

964 name the commit. In the above example, 'master' and 'mybranch'

965 are branch heads. 'master^' is the first parent of 'master'

966 -branch head. Please see 'git-rev-parse' documentation if you

966 +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 'git-show-branch'

973 -documentation for details.

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

Documentation/gitcvs-migration.txt

+2 -2

@@ -53,7 +53,7 @@ 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 linkgit:git-push[1] command:

56 +your changes, and then using the `git-push` command:

57

58 ------------------------------------------------

59 $ git push origin master

@@ -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 linkgit:git-cvsimport[1]:

121 +of the project you are interested in and run `git-cvsimport`:

122

123 -------------------------------------------

124 $ git cvsimport -C <destination> <module>

Documentation/gitdiffcore.txt

+17 -17

@@ -12,9 +12,9 @@ git diff *

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(1) output. The manipulation

17 +unconventional ways before showing `diff` output. The manipulation

18 is collectively called "diffcore transformation". This short note

19 describes what they are and how to use them to produce diff outputs

20 that are easier to understand than the conventional kind.

@@ -23,18 +23,18 @@ that are easier to understand than the conventional kind.

23 The chain of operation

24 ----------------------

25

26 -The git-diff-* 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-\*

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-\* 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-* 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:

@@ -84,11 +84,11 @@ of filepairs included:

84 :100644 100644 bcd1234... 0123456... M junkfile

85 ------------------------------------------------

86

87 -but the command invocation was "git diff-files myfile", then the

87 +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-* 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-* 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-\* 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-\* 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-*

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-* 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/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 -linkgit:git-ls-files[1] and linkgit:git-read-tree[1], 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 linkgit:git-status[1] and linkgit:git-add[1],

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

+2 -1

@@ -22,7 +22,8 @@ git repository.

22 OPTIONS

23 -------

24 To control which revisions to shown, the command takes options applicable to

25 -the linkgit:git-rev-list[1] command. This manual page describes only the most

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

29 -n <number>::

Documentation/gitrepository-layout.txt

+1 -1

@@ -178,7 +178,7 @@ remotes::

178

179 logs::

180 Records of changes made to refs are stored in this

181 - directory. See the documentation on git-update-ref

181 + directory. See linkgit:git-update-ref[1]

182 for more information.

183

184 logs/refs/heads/`name`::

Documentation/gittutorial-2.txt

+14 -14

@@ -54,7 +54,7 @@ following the example above generates a different SHA1 hash than

54 the one shown above because the commit object records the time when

55 it was created and the name of the person performing the commit.

56

57 -We can ask git about this particular object with the cat-file

57 +We can ask git about this particular object with the `cat-file`

58 command. Don't copy the 40 hex digits from this example but use those

59 from your own version. Note that you can shorten it to only a few

60 characters to save yourself typing all 40 hex digits:

@@ -212,8 +212,8 @@ designate such an argument.

212 The index file

213 --------------

214

215 -The primary tool we've been using to create commits is "git-commit

216 --a", which creates a commit including every change you've made to

215 +The primary tool we've been using to create commits is `git-commit

216 +-a`, which creates a commit including every change you've made to

217 your working tree. But what if you want to commit changes only to

218 certain files? Or only certain changes to certain files?

219

@@ -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,8 +311,8 @@ index a042389..513feba 100644

311 +hello world, again

312 ------------------------------------------------

313

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

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:

318

@@ -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

333 -the working tree; the -a option to commit tells it to first update

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

@@ -382,7 +382,7 @@ it is marked "changed but not updated". At this point, running "git

382 commit" would create a commit that added closing.txt (with its new

383 contents), but that didn't modify file.txt.

384

385 -Also, note that a bare "git diff" shows the changes to file.txt, but

385 +Also, note that a bare `git diff` shows the changes to file.txt, but

386 not the addition of closing.txt, because the version of closing.txt

387 in the index file is identical to the one in the working directory.

388

Documentation/gittutorial.txt

+23 -23

@@ -20,7 +20,7 @@ for example, to test the latest version, you may prefer to start with

20 the first two chapters of link:user-manual.html[The Git User's Manual].

21

22 First, note that you can get documentation for a command such as

23 -"git log --graph" with:

23 +`git log --graph` with:

24

25 ------------------------------------------------

26 $ man git-log

@@ -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 linkgit:git-add[1]:

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 linkgit:git-commit[1]:

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 linkgit:git-diff[1] with the --cached option:

88 +using `git-diff` with the --cached option:

89

90 ------------------------------------------------

91 $ git diff --cached

92 ------------------------------------------------

93

94 -(Without --cached, linkgit:git-diff[1] 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 linkgit:git-status[1]:

96 +summary of the situation with `git-status`:

97

98 ------------------------------------------------

99 $ git status

@@ -136,8 +136,8 @@ commit in the body.

136 Git tracks content not files

137 ----------------------------

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

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

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

@@ -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 -------------------------------------

@@ -368,8 +368,8 @@ $ git config --get remote.origin.url

368 /home/alice/project

369 -------------------------------------

370

371 -(The complete configuration created by git-clone is visible using

372 -"git config -l", and the linkgit:git-config[1] man page

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

375 Git also keeps a pristine copy of Alice's master branch under the

@@ -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 linkgit:git-revert[1]

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,13 +523,13 @@ $ 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,

532 -or git itself) have frequent merges, and gitk does a better job of

532 +or git itself) have frequent merges, and `gitk` does a better job of

533 visualizing their history. For example,

534

535 -------------------------------------

@@ -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 formatting and cleanup