6cf378f0cb · matheusbsbs/matheus-bagliano

Documentation/Makefile

+1 -1

@@ -82,7 +82,7 @@ endif

82 #

83

84 ifndef ASCIIDOC7

85 -ASCIIDOC_EXTRA += -a asciidoc7compatible -a no-inline-literal

85 +ASCIIDOC_EXTRA += -a asciidoc7compatible

86 endif

87 ifdef DOCBOOK_XSL_172

88 ASCIIDOC_EXTRA += -a git-asciidoc-no-roff

Documentation/config.txt

+18 -18

@@ -463,8 +463,8 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.

463 core.excludesfile::

464 In addition to '.gitignore' (per-directory) and

465 '.git/info/exclude', git looks into this file for patterns

466 - of files which are not meant to be tracked. "{tilde}/" is expanded

467 - to the value of `$HOME` and "{tilde}user/" to the specified user's

466 + of files which are not meant to be tracked. "`~/`" is expanded

467 + to the value of `$HOME` and "`~user/`" to the specified user's

468 home directory. See linkgit:gitignore[5].

469

470 core.askpass::

@@ -845,7 +845,7 @@ commit.status::

845

846 commit.template::

847 Specify a file to use as the template for new commit messages.

848 - "{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the

848 + "`~/`" is expanded to the value of `$HOME` and "`~user/`" to the

849 specified user's home directory.

850

851 credential.helper::

@@ -970,7 +970,7 @@ format.thread::

970 a boolean value, or `shallow` or `deep`. `shallow` threading

971 makes every mail a reply to the head of the series,

972 where the head is chosen from the cover letter, the

973 - `\--in-reply-to`, and the first patch mail, in this order.

973 + `--in-reply-to`, and the first patch mail, in this order.

974 `deep` threading makes every mail a reply to the previous one.

975 A true boolean value is the same as `shallow`, and a false

976 value disables threading.

@@ -1401,7 +1401,7 @@ instaweb.port::

1401 interactive.singlekey::

1402 In interactive commands, allow the user to provide one-letter

1403 input with a single key (i.e., without hitting enter).

1404 - Currently this is used by the `\--patch` mode of

1404 + Currently this is used by the `--patch` mode of

1405 linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1],

1406 linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this

1407 setting is silently ignored if portable keystroke input

@@ -1409,13 +1409,13 @@ interactive.singlekey::

1409

1410 log.abbrevCommit::

1411 If true, makes linkgit:git-log[1], linkgit:git-show[1], and

1412 - linkgit:git-whatchanged[1] assume `\--abbrev-commit`. You may

1413 - override this option with `\--no-abbrev-commit`.

1412 + linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may

1413 + override this option with `--no-abbrev-commit`.

1414

1415 log.date::

1416 Set the default date-time mode for the 'log' command.

1417 Setting a value for log.date is similar to using 'git log''s

1418 - `\--date` option. Possible values are `relative`, `local`,

1418 + `--date` option. Possible values are `relative`, `local`,

1419 `default`, `iso`, `rfc`, and `short`; see linkgit:git-log[1]

1420 for details.

1421

@@ -1605,18 +1605,18 @@ pack.indexVersion::

1605 and this config option ignored whenever the corresponding pack is

1606 larger than 2 GB.

1607 +

1608 -If you have an old git that does not understand the version 2 `{asterisk}.idx` file,

1608 +If you have an old git that does not understand the version 2 `*.idx` file,

1609 cloning or fetching over a non native protocol (e.g. "http" and "rsync")

1610 -that will copy both `{asterisk}.pack` file and corresponding `{asterisk}.idx` file from the

1610 +that will copy both `*.pack` file and corresponding `*.idx` file from the

1611 other side may give you a repository that cannot be accessed with your

1612 -older version of git. If the `{asterisk}.pack` file is smaller than 2 GB, however,

1612 +older version of git. If the `*.pack` file is smaller than 2 GB, however,

1613 you can use linkgit:git-index-pack[1] on the *.pack file to regenerate

1614 -the `{asterisk}.idx` file.

1614 +the `*.idx` file.

1615

1616 pack.packSizeLimit::

1617 The maximum size of a pack. This setting only affects

1618 packing to a file when repacking, i.e. the git:// protocol

1619 - is unaffected. It can be overridden by the `\--max-pack-size`

1619 + is unaffected. It can be overridden by the `--max-pack-size`

1620 option of linkgit:git-repack[1]. The minimum size allowed is

1621 limited to 1 MiB. The default is unlimited.

1622 Common unit suffixes of 'k', 'm', or 'g' are

@@ -1626,8 +1626,8 @@ pager.<cmd>::

1626 If the value is boolean, turns on or off pagination of the

1627 output of a particular git subcommand when writing to a tty.

1628 Otherwise, turns on pagination for the subcommand using the

1629 - pager specified by the value of `pager.<cmd>`. If `\--paginate`

1630 - or `\--no-pager` is specified on the command line, it takes

1629 + pager specified by the value of `pager.<cmd>`. If `--paginate`

1630 + or `--no-pager` is specified on the command line, it takes

1631 precedence over this option. To disable pagination for all

1632 commands, set `core.pager` or `GIT_PAGER` to `cat`.

1633

@@ -1635,9 +1635,9 @@ pretty.<name>::

1635 Alias for a --pretty= format string, as specified in

1636 linkgit:git-log[1]. Any aliases defined here can be used just

1637 as the built-in pretty formats could. For example,

1638 - running `git config pretty.changelog "format:{asterisk} %H %s"`

1638 + running `git config pretty.changelog "format:* %H %s"`

1639 would cause the invocation `git log --pretty=changelog`

1640 - to be equivalent to running `git log "--pretty=format:{asterisk} %H %s"`.

1640 + to be equivalent to running `git log "--pretty=format:* %H %s"`.

1641 Note that an alias with the same name as a built-in format

1642 will be silently ignored.

1643

@@ -1750,7 +1750,7 @@ remote.<name>.push::

1750

1751 remote.<name>.mirror::

1752 If true, pushing to this remote will automatically behave

1753 - as if the `\--mirror` option was given on the command line.

1753 + as if the `--mirror` option was given on the command line.

1754

1755 remote.<name>.skipDefaultUpdate::

1756 If true, this remote will be skipped by default when updating

Documentation/diff-generate-patch.txt

+1 -1

@@ -175,7 +175,7 @@ In the above example output, the function signature was changed

175 from both files (hence two `-` removals from both file1 and

176 file2, plus `++` to mean one line that was added does not appear

177 in either file1 nor file2). Also eight other lines are the same

178 -from file1 but do not appear in file2 (hence prefixed with `{plus}`).

178 +from file1 but do not appear in file2 (hence prefixed with `+`).

179

180 When shown by `git diff-tree -c`, it compares the parents of a

181 merge commit with the merge result (i.e. file1..fileN are the

Documentation/diff-options.txt

+1 -1

@@ -74,7 +74,7 @@ These parameters can also be set individually with `--stat-width=<width>`,

74 `--stat-name-width=<name-width>` and `--stat-count=<count>`.

75

76 --numstat::

77 - Similar to `\--stat`, but shows number of added and

77 + Similar to `--stat`, but shows number of added and

78 deleted lines in decimal notation and pathname without

79 abbreviation, to make it more machine friendly. For

80 binary files, outputs two `-` instead of saying

Documentation/everyday.txt

+2 -2

@@ -98,8 +98,8 @@ you originally wrote.

98 <9> switch to the master branch.

99 <10> merge a topic branch into your master branch.

100 <11> review commit logs; other forms to limit output can be

101 -combined and include `\--max-count=10` (show 10 commits),

102 -`\--until=2005-12-10`, etc.

101 +combined and include `--max-count=10` (show 10 commits),

102 +`--until=2005-12-10`, etc.

103 <12> view only the changes that touch what's in `curses/`

104 directory, since `v2.43` tag.

105

Documentation/git-archive.txt

+1 -1

@@ -160,7 +160,7 @@ EXAMPLES

160

161 Same as above, but the format is inferred from the output file.

162

163 -`git archive --format=tar --prefix=git-1.4.0/ v1.4.0{caret}\{tree\} | gzip >git-1.4.0.tar.gz`::

163 +`git archive --format=tar --prefix=git-1.4.0/ v1.4.0^{tree} | gzip >git-1.4.0.tar.gz`::

164

165 Create a compressed tarball for v1.4.0 release, but without a

166 global extended pax header.

Documentation/git-blame.txt

+1 -1

@@ -160,7 +160,7 @@ introduced the file with:

160 git log --diff-filter=A --pretty=short -- foo

161

162 and then annotate the change between the commit and its

163 -parents, using `commit{caret}!` notation:

163 +parents, using `commit^!` notation:

164

165 git blame -C -C -f $commit^! -- foo

166

Documentation/git-bundle.txt

+4 -4

@@ -61,7 +61,7 @@ unbundle <file>::

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

62 'git rev-list' (and containing a named ref, see SPECIFYING REFERENCES

63 below), that specifies the specific objects and references

64 - to transport. For example, `master{tilde}10..master` causes the

64 + to transport. For example, `master~10..master` causes the

65 current master reference to be packaged along with all objects

66 added since its 10th ancestor commit. There is no explicit

67 limit to the number of references and objects that may be

@@ -80,12 +80,12 @@ SPECIFYING REFERENCES

80

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

82 'git show-ref': this includes heads, tags, and remote heads. References

83 -such as `master{tilde}1` cannot be packaged, but are perfectly suitable for

83 +such as `master~1` cannot be packaged, but are perfectly suitable for

84 defining the basis. More than one reference may be packaged, and more

85 than one basis can be specified. The objects packaged are those not

86 contained in the union of the given bases. Each basis can be

87 -specified explicitly (e.g. `^master{tilde}10`), or implicitly (e.g.

88 -`master{tilde}10..master`, `--since=10.days.ago master`).

87 +specified explicitly (e.g. `^master~10`), or implicitly (e.g.

88 +`master~10..master`, `--since=10.days.ago master`).

89

90 It is very important that the basis used be held by the destination.

91 It is okay to err on the side of caution, causing the bundle file

Documentation/git-check-ref-format.txt

+6 -6

@@ -40,9 +40,9 @@ git imposes the following rules on how references are named:

40

41 . They cannot have ASCII control characters (i.e. bytes whose

42 values are lower than \040, or \177 `DEL`), space, tilde `~`,

43 - caret `{caret}`, or colon `:` anywhere.

43 + caret `^`, or colon `:` anywhere.

44

45 -. They cannot have question-mark `?`, asterisk `{asterisk}`, or open

45 +. They cannot have question-mark `?`, asterisk `*`, or open

46 bracket `[` anywhere. See the `--refspec-pattern` option below for

47 an exception to this rule.

48

@@ -62,10 +62,10 @@ unquoted (by mistake), and also avoids ambiguities in certain

62 reference name expressions (see linkgit:gitrevisions[7]):

63

64 . A double-dot `..` is often used as in `ref1..ref2`, and in some

65 - contexts this notation means `{caret}ref1 ref2` (i.e. not in

65 + contexts this notation means `^ref1 ref2` (i.e. not in

66 `ref1` and in `ref2`).

67

68 -. A tilde `~` and caret `{caret}` are used to introduce the postfix

68 +. A tilde `~` and caret `^` are used to introduce the postfix

69 'nth parent' and 'peel onion' operation.

70

71 . A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s

@@ -92,9 +92,9 @@ OPTIONS

92 --refspec-pattern::

93 Interpret <refname> as a reference name pattern for a refspec

94 (as used with remote repositories). If this option is

95 - enabled, <refname> is allowed to contain a single `{asterisk}`

95 + enabled, <refname> is allowed to contain a single `*`

96 in place of a one full pathname component (e.g.,

97 - `foo/{asterisk}/bar` but not `foo/bar{asterisk}`).

97 + `foo/*/bar` but not `foo/bar*`).

98

99 --normalize::

100 Normalize 'refname' by removing any leading slash (`/`)

Documentation/git-checkout.txt

+4 -4

@@ -184,7 +184,7 @@ the conflicted merge in the specified paths.

184 +

185 This means that you can use `git checkout -p` to selectively discard

186 edits from your current working tree. See the ``Interactive Mode''

187 -section of linkgit:git-add[1] to learn how to operate the `\--patch` mode.

187 +section of linkgit:git-add[1] to learn how to operate the `--patch` mode.

188

189 <branch>::

190 Branch to checkout; if it refers to a branch (i.e., a name that,

@@ -193,11 +193,11 @@ section of linkgit:git-add[1] to learn how to operate the `\--patch` mode.

193 commit, your HEAD becomes "detached" and you are no longer on

194 any branch (see below for details).

195 +

196 -As a special case, the `"@\{-N\}"` syntax for the N-th last branch

196 +As a special case, the `"@{-N}"` syntax for the N-th last branch

197 checks out the branch (instead of detaching). You may also specify

198 -`-` which is synonymous with `"@\{-1\}"`.

198 +`-` which is synonymous with `"@{-1}"`.

199 +

200 -As a further special case, you may use `"A\...B"` as a shortcut for the

200 +As a further special case, you may use `"A...B"` as a shortcut for the

201 merge base of `A` and `B` if there is exactly one merge base. You can

202 leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.

203

Documentation/git-cherry-pick.txt

+2 -2

@@ -130,7 +130,7 @@ EXAMPLES

130 Apply the changes introduced by all commits that are ancestors

131 of master but not of HEAD to produce new commits.

132

133 -`git cherry-pick master{tilde}4 master{tilde}2`::

133 +`git cherry-pick master~4 master~2`::

134

135 Apply the changes introduced by the fifth and third last

136 commits pointed to by master and create 2 new commits with

@@ -151,7 +151,7 @@ EXAMPLES

151 are in next but not HEAD to the current branch, creating a new

152 commit for each new change.

153

154 -`git rev-list --reverse master \-- README | git cherry-pick -n --stdin`::

154 +`git rev-list --reverse master -- README | git cherry-pick -n --stdin`::

155

156 Apply the changes introduced by all commits on the master

157 branch that touched README to the working tree and index,

Documentation/git-commit.txt

+2 -2

@@ -42,7 +42,7 @@ The content to be added can be specified in several ways:

42

43 5. by using the --interactive or --patch switches with the 'commit' command

44 to decide one by one which files or hunks should be part of the commit,

45 - before finalizing the operation. See the ``Interactive Mode`` section of

45 + before finalizing the operation. See the ``Interactive Mode'' section of

46 linkgit:git-add[1] to learn how to operate these modes.

47

48 The `--dry-run` option can be used to obtain a

@@ -287,7 +287,7 @@ When recording your own work, the contents of modified files in

287 your working tree are temporarily stored to a staging area

288 called the "index" with 'git add'. A file can be

289 reverted back, only in the index but not in the working tree,

290 -to that of the last commit with `git reset HEAD \-- <file>`,

290 +to that of the last commit with `git reset HEAD -- <file>`,

291 which effectively reverts 'git add' and prevents the changes to

292 this file from participating in the next commit. After building

293 the state to be committed incrementally with these commands,

Documentation/git-cvsserver.txt

+1 -1

@@ -252,7 +252,7 @@ Configuring database backend

252

253 'git-cvsserver' uses the Perl DBI module. Please also read

254 its documentation if changing these variables, especially

255 -about `DBI\->connect()`.

255 +about `DBI->connect()`.

256

257 gitcvs.dbname::

258 Database name. The exact meaning depends on the

Documentation/git-fast-export.txt

+1 -1

@@ -104,7 +104,7 @@ marks the same across runs.

104 [<git-rev-list-args>...]::

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

106 'git rev-list', that specifies the specific objects and references

107 - to export. For example, `master{tilde}10..master` causes the

107 + to export. For example, `master~10..master` causes the

108 current master reference to be exported along with all objects

109 added since its 10th ancestor commit.

110

Documentation/git-fast-import.txt

+3 -3

@@ -478,9 +478,9 @@ current branch value should be written as:

478 ----

479 from refs/heads/branch^0

480 ----

481 -The `{caret}0` suffix is necessary as fast-import does not permit a branch to

481 +The `^0` suffix is necessary as fast-import does not permit a branch to

482 start from itself, and the branch is created in memory before the

483 -`from` command is even read from the input. Adding `{caret}0` will force

483 +`from` command is even read from the input. Adding `^0` will force

484 fast-import to resolve the commit through Git's revision parsing library,

485 rather than its internal branch table, thereby loading in the

486 existing value of the branch.

@@ -975,7 +975,7 @@ Reading from a named tree::

975

976 See `filemodify` above for a detailed description of `<path>`.

977

978 -Output uses the same format as `git ls-tree <tree> {litdd} <path>`:

978 +Output uses the same format as `git ls-tree <tree> -- <path>`:

979

980 ====

981 <mode> SP ('blob' | 'tree' | 'commit') SP <dataref> HT <path> LF

Documentation/git-filter-branch.txt

+17 -17

@@ -96,8 +96,8 @@ OPTIONS

96 --index-filter <command>::

97 This is the filter for rewriting the index. It is similar to the

98 tree filter but does not check out the tree, which makes it much

99 - faster. Frequently used with `git rm \--cached

100 - \--ignore-unmatch ...`, see EXAMPLES below. For hairy

99 + faster. Frequently used with `git rm --cached

100 + --ignore-unmatch ...`, see EXAMPLES below. For hairy

101 cases, see linkgit:git-update-index[1].

102

103 --parent-filter <command>::

@@ -222,11 +222,11 @@ However, if the file is absent from the tree of some commit,

222 a simple `rm filename` will fail for that tree and commit.

223 Thus you may instead want to use `rm -f filename` as the script.

224

225 -Using `\--index-filter` with 'git rm' yields a significantly faster

225 +Using `--index-filter` with 'git rm' yields a significantly faster

226 version. Like with using `rm filename`, `git rm --cached filename`

227 will fail if the file is absent from the tree of a commit. If you

228 want to "completely forget" a file, it does not matter when it entered

229 -history, so we also add `\--ignore-unmatch`:

229 +history, so we also add `--ignore-unmatch`:

230

231 --------------------------------------------------------------------------

232 git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD

@@ -242,8 +242,8 @@ git filter-branch --subdirectory-filter foodir -- --all

242 -------------------------------------------------------

243

244 Thus you can, e.g., turn a library subdirectory into a repository of

245 -its own. Note the `\--` that separates 'filter-branch' options from

246 -revision options, and the `\--all` to rewrite all branches and tags.

245 +its own. Note the `--` that separates 'filter-branch' options from

246 +revision options, and the `--all` to rewrite all branches and tags.

247

248 To set a commit (which typically is at the tip of another

249 history) to be the parent of the current initial commit, in

@@ -371,23 +371,23 @@ Checklist for Shrinking a Repository

371 ------------------------------------

372

373 git-filter-branch is often used to get rid of a subset of files,

374 -usually with some combination of `\--index-filter` and

375 -`\--subdirectory-filter`. People expect the resulting repository to

374 +usually with some combination of `--index-filter` and

375 +`--subdirectory-filter`. People expect the resulting repository to

376 be smaller than the original, but you need a few more steps to

377 actually make it smaller, because git tries hard not to lose your

378 objects until you tell it to. First make sure that:

379

380 * You really removed all variants of a filename, if a blob was moved

381 - over its lifetime. `git log \--name-only \--follow \--all \--

382 - filename` can help you find renames.

381 + over its lifetime. `git log --name-only --follow --all -- filename`

382 + can help you find renames.

383

384 -* You really filtered all refs: use `\--tag-name-filter cat \--

385 - \--all` when calling git-filter-branch.

384 +* You really filtered all refs: use `--tag-name-filter cat -- --all`

385 + when calling git-filter-branch.

386

387 Then there are two ways to get a smaller repository. A safer way is

388 to clone, that keeps your original intact.

389

390 -* Clone it with `git clone +++file:///path/to/repo+++`. The clone

390 +* Clone it with `git clone file:///path/to/repo`. The clone

391 will not have the removed objects. See linkgit:git-clone[1]. (Note

392 that cloning with a plain path just hardlinks everything!)

393

@@ -397,14 +397,14 @@ approach, so *make a backup* or go back to cloning it. You have been

397 warned.

398

399 * Remove the original refs backed up by git-filter-branch: say `git

400 - for-each-ref \--format="%(refname)" refs/original/ | xargs -n 1 git

400 + for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git

401 update-ref -d`.

402

403 -* Expire all reflogs with `git reflog expire \--expire=now \--all`.

403 +* Expire all reflogs with `git reflog expire --expire=now --all`.

404

405 -* Garbage collect all unreferenced objects with `git gc \--prune=now`

405 +* Garbage collect all unreferenced objects with `git gc --prune=now`

406 (or if your git-gc is not new enough to support arguments to

407 - `\--prune`, use `git repack -ad; git prune` instead).

407 + `--prune`, use `git repack -ad; git prune` instead).

408

409 GIT

410 ---

Documentation/git-format-patch.txt

+2 -2

@@ -45,7 +45,7 @@ There are two ways to specify which commits to operate on.

45 The first rule takes precedence in the case of a single <commit>. To

46 apply the second rule, i.e., format everything since the beginning of

47 history up until <commit>, use the '\--root' option: `git format-patch

48 -\--root <commit>`. If you want to format only <commit> itself, you

48 +--root <commit>`. If you want to format only <commit> itself, you

49 can do this with `git format-patch -1 <commit>`.

50

51 By default, each output file is numbered sequentially from 1, and uses the

@@ -134,7 +134,7 @@ include::diff-options.txt[]

134 The optional <style> argument can be either `shallow` or `deep`.

135 'shallow' threading makes every mail a reply to the head of the

136 series, where the head is chosen from the cover letter, the

137 -`\--in-reply-to`, and the first patch mail, in this order. 'deep'

137 +`--in-reply-to`, and the first patch mail, in this order. 'deep'

138 threading makes every mail a reply to the previous one.

139 +

140 The default is `--no-thread`, unless the 'format.thread' configuration

Documentation/git-gc.txt

+1 -1

@@ -84,7 +84,7 @@ The optional configuration variable 'gc.reflogExpireUnreachable'

84 can be set to indicate how long historical reflog entries which

85 are not part of the current branch should remain available in

86 this repository. These types of entries are generally created as

87 -a result of using `git commit \--amend` or `git rebase` and are the

87 +a result of using `git commit --amend` or `git rebase` and are the

88 commits prior to the amend or rebase occurring. Since these changes

89 are not part of the current project most users will want to expire

90 them sooner. This option defaults to '30 days'.

Documentation/git-grep.txt

+2 -2

@@ -247,11 +247,11 @@ OPTIONS

247 Examples

248 --------

249

250 -`git grep {apostrophe}time_t{apostrophe} \-- {apostrophe}*.[ch]{apostrophe}`::

250 +`git grep 'time_t' -- '*.[ch]'`::

251 Looks for `time_t` in all tracked .c and .h files in the working

252 directory and its subdirectories.

253

254 -`git grep -e {apostrophe}#define{apostrophe} --and $ -e MAX_PATH -e PATH_MAX $`::

254 +`git grep -e '#define' --and $ -e MAX_PATH -e PATH_MAX $`::

255 Looks for a line that has `#define` and either `MAX_PATH` or

256 `PATH_MAX`.

257

Documentation/git-log.txt

+1 -1

@@ -100,7 +100,7 @@ Examples

100 Show all commits since version 'v2.6.12' that changed any file

101 in the include/scsi or drivers/scsi subdirectories

102

103 -`git log --since="2 weeks ago" \-- gitk`::

103 +`git log --since="2 weeks ago" -- gitk`::

104

105 Show the changes during the last two weeks to the file 'gitk'.

106 The "--" is necessary to avoid confusion with the *branch* named

Documentation/git-notes.txt

+1 -1

@@ -70,7 +70,7 @@ copy::

70 second object). This subcommand is equivalent to:

71 `git notes add [-f] -C $(git notes list <from-object>) <to-object>`

72 +

73 -In `\--stdin` mode, take lines in the format

73 +In `--stdin` mode, take lines in the format

74 +

75 ----------

76 <from-object> SP <to-object> [ SP <rest> ] LF

Documentation/git-pack-refs.txt

+1 -1

@@ -32,7 +32,7 @@ Subsequent updates to branches always create new files under

32

33 A recommended practice to deal with a repository with too many

34 refs is to pack its refs with `--all --prune` once, and

35 -occasionally run `git pack-refs \--prune`. Tags are by

35 +occasionally run `git pack-refs --prune`. Tags are by

36 definition stationary and are not expected to change. Branch

37 heads will be packed with the initial `pack-refs --all`, but

38 only the currently active branch heads will become unpacked,

Documentation/git-pull.txt

+1 -1

@@ -110,7 +110,7 @@ include::merge-options.txt[]

110 +

111 See `pull.rebase`, `branch.<name>.rebase` and `branch.autosetuprebase` in

112 linkgit:git-config[1] if you want to make `git pull` always use

113 -`{litdd}rebase` instead of merging.

113 +`--rebase` instead of merging.

114 +

115 [NOTE]

116 This is a potentially _dangerous_ mode of operation.

Documentation/git-push.txt

+7 -7

@@ -34,7 +34,7 @@ OPTIONS[[OPTIONS]]

34

35 <refspec>...::

36 The format of a <refspec> parameter is an optional plus

37 - `{plus}`, followed by the source ref <src>, followed

37 + `+`, followed by the source ref <src>, followed

38 by a colon `:`, followed by the destination ref <dst>.

39 It is used to specify with what <src> object the <dst> ref

40 in the remote repository is to be updated.

@@ -50,7 +50,7 @@ updated.

50 +

51 The object referenced by <src> is used to update the <dst> reference

52 on the remote side, but by default this is only allowed if the

53 -update can fast-forward <dst>. By having the optional leading `{plus}`,

53 +update can fast-forward <dst>. By having the optional leading `+`,

54 you can tell git to update the <dst> ref even when the update is not a

55 fast-forward. This does *not* attempt to merge <src> into <dst>. See

56 EXAMPLES below for details.

@@ -60,7 +60,7 @@ EXAMPLES below for details.

60 Pushing an empty <src> allows you to delete the <dst> ref from

61 the remote repository.

62 +

63 -The special refspec `:` (or `{plus}:` to allow non-fast-forward updates)

63 +The special refspec `:` (or `+:` to allow non-fast-forward updates)

64 directs git to push "matching" branches: for every branch that exists on

65 the local side, the remote side is updated if a branch of the same name

66 already exists on the remote side. This is the default operation mode

@@ -75,7 +75,7 @@ nor in any Push line of the corresponding remotes file---see below).

75 Remove remote branches that don't have a local counterpart. For example

76 a remote branch `tmp` will be removed if a local branch with the same

77 name doesn't exist any more. This also respects refspecs, e.g.

78 - `git push --prune remote refs/heads/{asterisk}:refs/tmp/{asterisk}` would

78 + `git push --prune remote refs/heads/*:refs/tmp/*` would

79 make sure that remote `refs/tmp/foo` will be removed if `refs/heads/foo`

80 doesn't exist.

81

@@ -204,7 +204,7 @@ option is used.

204 flag::

205 A single character indicating the status of the ref:

206 (space);; for a successfully pushed fast-forward;

207 -`{plus}`;; for a successful forced update;

207 +`+`;; for a successful forced update;

208 `-`;; for a successfully deleted ref;

209 `*`;; for a successfully pushed new ref;

210 `!`;; for a ref that was rejected or failed to push; and

@@ -214,7 +214,7 @@ summary::

214 For a successfully pushed ref, the summary shows the old and new

215 values of the ref in a form suitable for using as an argument to

216 `git log` (this is `<old>..<new>` in most cases, and

217 - `<old>\...<new>` for forced non-fast-forward updates).

217 + `<old>...<new>` for forced non-fast-forward updates).

218 +

219 For a failed update, more details are given:

220 +

@@ -396,7 +396,7 @@ the ones in the examples below) can be configured as the default for

396 Find a ref that matches `experimental` in the `origin` repository

397 (e.g. `refs/heads/experimental`), and delete it.

398

399 -`git push origin {plus}dev:master`::

399 +`git push origin +dev:master`::

400 Update the origin repository's master branch with the dev branch,

401 allowing non-fast-forward updates. *This can leave unreferenced

402 commits dangling in the origin repository.* Consider the

Documentation/git-rebase.txt

+5 -5

@@ -267,7 +267,7 @@ which makes little sense.

267 -X <strategy-option>::

268 --strategy-option=<strategy-option>::

269 Pass the <strategy-option> through to the merge strategy.

270 - This implies `\--merge` and, if no strategy has been

270 + This implies `--merge` and, if no strategy has been

271 specified, `-s recursive`. Note the reversal of 'ours' and

272 'theirs' as noted in above for the `-m` option.

273

@@ -611,8 +611,8 @@ Easy case: The changes are literally the same.::

611 Hard case: The changes are not the same.::

612

613 This happens if the 'subsystem' rebase had conflicts, or used

614 - `\--interactive` to omit, edit, squash, or fixup commits; or

615 - if the upstream used one of `commit \--amend`, `reset`, or

614 + `--interactive` to omit, edit, squash, or fixup commits; or

615 + if the upstream used one of `commit --amend`, `reset`, or

616 `filter-branch`.

617

618

@@ -648,7 +648,7 @@ correspond to the ones before the rebase.

648 NOTE: While an "easy case recovery" sometimes appears to be successful

649 even in the hard case, it may have unintended consequences. For

650 example, a commit that was removed via `git rebase

651 - \--interactive` will be **resurrected**!

651 + --interactive` will be **resurrected**!

652

653 The idea is to manually tell 'git rebase' "where the old 'subsystem'

654 ended and your 'topic' began", that is, what the old merge-base

@@ -656,7 +656,7 @@ between them was. You will have to find a way to name the last commit

656 of the old 'subsystem', for example:

657

658 * With the 'subsystem' reflog: after 'git fetch', the old tip of

659 - 'subsystem' is at `subsystem@\{1}`. Subsequent fetches will

659 + 'subsystem' is at `subsystem@{1}`. Subsequent fetches will

660 increase the number. (See linkgit:git-reflog[1].)

661

662 * Relative to the tip of 'topic': knowing that your 'topic' has three

Documentation/git-reflog.txt

+3 -3

@@ -39,13 +39,13 @@ as well). It is an alias for `git log -g --abbrev-commit --pretty=oneline`;

39 see linkgit:git-log[1].

40

41 The reflog is useful in various git commands, to specify the old value

42 -of a reference. For example, `HEAD@\{2\}` means "where HEAD used to be

43 -two moves ago", `master@\{one.week.ago\}` means "where master used to

42 +of a reference. For example, `HEAD@{2}` means "where HEAD used to be

43 +two moves ago", `master@{one.week.ago}` means "where master used to

44 point to one week ago", and so on. See linkgit:gitrevisions[7] for

45 more details.

46

47 To delete single entries from the reflog, use the subcommand "delete"

48 -and specify the _exact_ entry (e.g. "`git reflog delete master@\{2\}`").

48 +and specify the _exact_ entry (e.g. "`git reflog delete master@{2}`").

49

50

51 OPTIONS

Documentation/git-remote-helpers.txt

+4 -4

@@ -87,7 +87,7 @@ to the `capabilities` command (see COMMANDS, below).

87 capability use this.

88 +

89 A helper advertising the capability

90 -`refspec refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}`

90 +`refspec refs/heads/*:refs/svn/origin/branches/*`

91 is saying that, when it is asked to `import refs/heads/topic`, the

92 stream it outputs will update the `refs/svn/origin/branches/topic`

93 ref.

@@ -96,7 +96,7 @@ This capability can be advertised multiple times. The first

96 applicable refspec takes precedence. The left-hand of refspecs

97 advertised with this capability must cover all refs reported by

98 the list command. If no 'refspec' capability is advertised,

99 -there is an implied `refspec {asterisk}:{asterisk}`.

99 +there is an implied `refspec *:*`.

100

101 Capabilities for Pushing

102 ~~~~~~~~~~~~~~~~~~~~~~~~

@@ -148,7 +148,7 @@ Other frontends may have some other order of preference.

148 This modifies the 'import' capability.

149 +

150 A helper advertising

151 -`refspec refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}`

151 +`refspec refs/heads/*:refs/svn/origin/branches/*`

152 in its capabilities is saying that, when it handles

153 `import refs/heads/topic`, the stream it outputs will update the

154 `refs/svn/origin/branches/topic` ref.

@@ -157,7 +157,7 @@ This capability can be advertised multiple times. The first

157 applicable refspec takes precedence. The left-hand of refspecs

158 advertised with this capability must cover all refs reported by

159 the list command. If no 'refspec' capability is advertised,

160 -there is an implied `refspec {asterisk}:{asterisk}`.

160 +there is an implied `refspec *:*`.

161

162 INVOCATION

163 ----------

Documentation/git-remote.txt

+3 -3

@@ -67,14 +67,14 @@ multiple branches without grabbing all branches.

67 With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` is set

68 up to point at remote's `<master>` branch. See also the set-head command.

69 +

70 -When a fetch mirror is created with `\--mirror=fetch`, the refs will not

70 +When a fetch mirror is created with `--mirror=fetch`, the refs will not

71 be stored in the 'refs/remotes/' namespace, but rather everything in

72 'refs/' on the remote will be directly mirrored into 'refs/' in the

73 local repository. This option only makes sense in bare repositories,

74 because a fetch would overwrite any local commits.

75 +

76 -When a push mirror is created with `\--mirror=push`, then `git push`

77 -will always behave as if `\--mirror` was passed.

76 +When a push mirror is created with `--mirror=push`, then `git push`

77 +will always behave as if `--mirror` was passed.

78

79 'rename'::

80

Documentation/git-rerere.txt

+3 -3

@@ -101,15 +101,15 @@ One way to do it is to pull master into the topic branch:

101

102 The commits marked with `*` touch the same area in the same

103 file; you need to resolve the conflicts when creating the commit

104 -marked with `{plus}`. Then you can test the result to make sure your

104 +marked with `+`. Then you can test the result to make sure your

105 work-in-progress still works with what is in the latest master.

106

107 After this test merge, there are two ways to continue your work

108 on the topic. The easiest is to build on top of the test merge

109 -commit `{plus}`, and when your work in the topic branch is finally

109 +commit `+`, and when your work in the topic branch is finally

110 ready, pull the topic branch into master, and/or ask the

111 upstream to pull from you. By that time, however, the master or

112 -the upstream might have been advanced since the test merge `{plus}`,

112 +the upstream might have been advanced since the test merge `+`,

113 in which case the final commit graph would look like this:

114

115 ------------

Documentation/git-reset.txt

+1 -1

@@ -41,7 +41,7 @@ working tree in one go.

41 +

42 This means that `git reset -p` is the opposite of `git add -p`, i.e.

43 you can use it to selectively reset hunks. See the ``Interactive Mode''

44 -section of linkgit:git-add[1] to learn how to operate the `\--patch` mode.

44 +section of linkgit:git-add[1] to learn how to operate the `--patch` mode.

45

46 'git reset' --<mode> [<commit>]::

47 This form resets the current branch head to <commit> and

Documentation/git-rev-parse.txt

+3 -4

@@ -113,15 +113,14 @@ OPTIONS

113 +

114 If a `pattern` is given, only refs matching the given shell glob are

115 shown. If the pattern does not contain a globbing character (`?`,

116 -`{asterisk}`, or `[`), it is turned into a prefix match by

117 -appending `/{asterisk}`.

116 +`*`, or `[`), it is turned into a prefix match by appending `/*`.

117

118 --glob=pattern::

119 Show all refs matching the shell glob pattern `pattern`. If

120 the pattern does not start with `refs/`, this is automatically

121 prepended. If the pattern does not contain a globbing

123 - character (`?`, `{asterisk}`, or `[`), it is turned into a prefix

124 - match by appending `/{asterisk}`.

122 + character (`?`, `*`, or `[`), it is turned into a prefix

123 + match by appending `/*`.

124

125 --show-toplevel::

126 Show the absolute path of the top-level directory.

Documentation/git-revert.txt

+2 -2

@@ -27,7 +27,7 @@ throw away all uncommitted changes in your working directory, you

27 should see linkgit:git-reset[1], particularly the '--hard' option. If

28 you want to extract specific files as they were in another commit, you

29 should see linkgit:git-checkout[1], specifically the `git checkout

30 -<commit> \-- <filename>` syntax. Take care with these alternatives as

30 +<commit> -- <filename>` syntax. Take care with these alternatives as

31 both will discard uncommitted changes in your working directory.

32

33 OPTIONS

@@ -105,7 +105,7 @@ EXAMPLES

105 Revert the changes specified by the fourth last commit in HEAD

106 and create a new commit with the reverted changes.

107

108 -`git revert -n master{tilde}5..master{tilde}2`::

108 +`git revert -n master~5..master~2`::

109

110 Revert the changes done by commits from the fifth last commit

111 in master (included) to the third last commit in master

Documentation/git-rm.txt

+1 -2

@@ -79,8 +79,7 @@ a file that you have not told git about does not remove that file.

79

80 File globbing matches across directory boundaries. Thus, given

81 two directories `d` and `d2`, there is a difference between

82 -using `git rm {apostrophe}d{asterisk}{apostrophe}` and

83 -`git rm {apostrophe}d/{asterisk}{apostrophe}`, as the former will

82 +using `git rm 'd*'` and `git rm 'd/*'`, as the former will

83 also remove all of directory `d2`.

84

85 REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM

Documentation/git-shortlog.txt

+1 -1

@@ -47,7 +47,7 @@ OPTIONS

47 --format[=<format>]::

48 Instead of the commit subject, use some other information to

49 describe each commit. '<format>' can be any string accepted

50 - by the `--format` option of 'git log', such as '{asterisk} [%h] %s'.

50 + by the `--format` option of 'git log', such as '* [%h] %s'.

51 (See the "PRETTY FORMATS" section of linkgit:git-log[1].)

52

53 Each pretty-printed commit will be rewrapped before it is shown.

Documentation/git-show-ref.txt

+1 -1

@@ -73,7 +73,7 @@ OPTIONS

73 --exclude-existing[=<pattern>]::

74

75 Make 'git show-ref' act as a filter that reads refs from stdin of the

76 - form "`{caret}(?:<anything>\s)?<refname>(?:{backslash}{caret}{})?$`"

76 + form "`^(?:<anything>\s)?<refname>(?:\^{})?$`"

77 and performs the following actions on each:

78 (1) strip "{caret}{}" at the end of line if any;

79 (2) ignore if pattern is provided and does not head-match refname;

Documentation/git-show.txt

+2 -2

@@ -52,10 +52,10 @@ EXAMPLES

52 Shows the tag `v1.0.0`, along with the object the tags

53 points at.

54

55 -`git show v1.0.0^\{tree\}`::

55 +`git show v1.0.0^{tree}`::

56 Shows the tree pointed to by the tag `v1.0.0`.

57

58 -`git show -s --format=%s v1.0.0^\{commit\}`::

58 +`git show -s --format=%s v1.0.0^{commit}`::

59 Shows the subject of the commit pointed to by the

60 tag `v1.0.0`.

61

Documentation/git-stash.txt

+9 -9

@@ -36,8 +36,8 @@ you create one.

36

37 The latest stash you created is stored in `refs/stash`; older

38 stashes are found in the reflog of this reference and can be named using

39 -the usual reflog syntax (e.g. `stash@\{0}` is the most recently

40 -created stash, `stash@\{1}` is the one before it, `stash@\{2.hours.ago}`

39 +the usual reflog syntax (e.g. `stash@{0}` is the most recently

40 +created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}`

41 is also possible).

42

43 OPTIONS

@@ -66,7 +66,7 @@ constructed such that its index state is the same as the index state

66 of your repository, and its worktree contains only the changes you

67 selected interactively. The selected changes are then rolled back

68 from your worktree. See the ``Interactive Mode'' section of

69 -linkgit:git-add[1] to learn how to operate the `\--patch` mode.

69 +linkgit:git-add[1] to learn how to operate the `--patch` mode.

70 +

71 The `--patch` option implies `--keep-index`. You can use

72 `--no-keep-index` to override this.

@@ -74,7 +74,7 @@ The `--patch` option implies `--keep-index`. You can use

74 list [<options>]::

75

76 List the stashes that you currently have. Each 'stash' is listed

77 - with its name (e.g. `stash@\{0}` is the latest stash, `stash@\{1}` is

77 + with its name (e.g. `stash@{0}` is the latest stash, `stash@{1}` is

78 the one before, etc.), the name of the branch that was current when the

79 stash was made, and a short description of the commit the stash was

80 based on.

@@ -93,7 +93,7 @@ show [<stash>]::

93 stashed state and its original parent. When no `<stash>` is given,

94 shows the latest one. By default, the command shows the diffstat, but

95 it will accept any format known to 'git diff' (e.g., `git stash show

96 - -p stash@\{1}` to view the second most recent stash in patch form).

96 + -p stash@{1}` to view the second most recent stash in patch form).

97

98 pop [--index] [-q|--quiet] [<stash>]::

99

@@ -111,8 +111,8 @@ tree's changes, but also the index's ones. However, this can fail, when you

111 have conflicts (which are stored in the index, where you therefore can no

112 longer apply the changes as they were originally).

113 +

114 -When no `<stash>` is given, `stash@\{0}` is assumed, otherwise `<stash>` must

115 -be a reference of the form `stash@\{<revision>}`.

114 +When no `<stash>` is given, `stash@{0}` is assumed, otherwise `<stash>` must

115 +be a reference of the form `stash@{<revision>}`.

116

117 apply [--index] [-q|--quiet] [<stash>]::

118

@@ -143,9 +143,9 @@ clear::

143 drop [-q|--quiet] [<stash>]::

144

145 Remove a single stashed state from the stash list. When no `<stash>`

146 - is given, it removes the latest one. i.e. `stash@\{0}`, otherwise

146 + is given, it removes the latest one. i.e. `stash@{0}`, otherwise

147 `<stash>` must a valid stash log reference of the form

148 - `stash@\{<revision>}`.

148 + `stash@{<revision>}`.

149

150 create::

151

Documentation/git-status.txt

+2 -2

@@ -98,12 +98,12 @@ In the short-format, the status of each path is shown as

98

99 XY PATH1 -> PATH2

100

101 -where `PATH1` is the path in the `HEAD`, and the ` \-> PATH2` part is

101 +where `PATH1` is the path in the `HEAD`, and the " `-> PATH2`" part is

102 shown only when `PATH1` corresponds to a different path in the

103 index/worktree (i.e. the file is renamed). The 'XY' is a two-letter

104 status code.

105

106 -The fields (including the `\->`) are separated from each other by a

106 +The fields (including the `->`) are separated from each other by a

107 single space. If a filename contains whitespace or other nonprintable

108 characters, that field will be quoted in the manner of a C string

109 literal: surrounded by ASCII double quote (34) characters, and with

Documentation/git-tar-tree.txt

+1 -1

@@ -63,7 +63,7 @@ EXAMPLES

63

64 Create a tarball for v1.4.0 release.

65

66 -`git tar-tree v1.4.0{caret}\{tree\} git-1.4.0 | gzip >git-1.4.0.tar.gz`::

66 +`git tar-tree v1.4.0^{tree} git-1.4.0 | gzip >git-1.4.0.tar.gz`::

67

68 Create a tarball for v1.4.0 release, but without a

69 global extended pax header.

Documentation/git-whatchanged.txt

+1 -1

@@ -58,7 +58,7 @@ Examples

58 Show as patches the commits since version 'v2.6.12' that changed

59 any file in the include/scsi or drivers/scsi subdirectories

60

61 -`git whatchanged --since="2 weeks ago" \-- gitk`::

61 +`git whatchanged --since="2 weeks ago" -- gitk`::

62

63 Show the changes during the last two weeks to the file 'gitk'.

64 The "--" is necessary to avoid confusion with the *branch* named

Documentation/gitcli.txt

+6 -6

@@ -25,22 +25,22 @@ arguments. Here are the rules:

25 are paths.

26

27 * When an argument can be misunderstood as either a revision or a path,

28 - they can be disambiguated by placing `\--` between them.

29 - E.g. `git diff \-- HEAD` is, "I have a file called HEAD in my work

28 + they can be disambiguated by placing `--` between them.

29 + E.g. `git diff -- HEAD` is, "I have a file called HEAD in my work

30 tree. Please show changes between the version I staged in the index

31 and what I have in the work tree for that file". not "show difference

32 between the HEAD commit and the work tree as a whole". You can say

33 - `git diff HEAD \--` to ask for the latter.

33 + `git diff HEAD --` to ask for the latter.

34

35 - * Without disambiguating `\--`, git makes a reasonable guess, but errors

35 + * Without disambiguating `--`, git makes a reasonable guess, but errors

36 out and asking you to disambiguate when ambiguous. E.g. if you have a

37 file called HEAD in your work tree, `git diff HEAD` is ambiguous, and

38 - you have to say either `git diff HEAD \--` or `git diff \-- HEAD` to

38 + you have to say either `git diff HEAD --` or `git diff -- HEAD` to

39 disambiguate.

40

41 When writing a script that is expected to handle random user-input, it is

42 a good practice to make it explicit which arguments are which by placing

43 -disambiguating `\--` at appropriate places.

43 +disambiguating `--` at appropriate places.

44

45 Here are the rules regarding the "flags" that you should follow when you are

46 scripting git:

Documentation/gitcore-tutorial.txt

+14 -14

@@ -151,8 +151,8 @@ to your working tree, you use the 'git update-index' program. That

151 program normally just takes a list of filenames you want to update, but

152 to avoid trivial mistakes, it refuses to add new entries to the index

153 (or remove existing ones) unless you explicitly tell it that you're

154 -adding a new entry with the `\--add` flag (or removing an entry with the

155 -`\--remove`) flag.

154 +adding a new entry with the `--add` flag (or removing an entry with the

155 +`--remove`) flag.

156

157 So to populate the index with the two files you just created, you can do

158

@@ -399,10 +399,10 @@ $ git diff HEAD

399 which ends up doing the above for you.

400

401 In other words, 'git diff-index' normally compares a tree against the

402 -working tree, but when given the `\--cached` flag, it is told to

402 +working tree, but when given the `--cached` flag, it is told to

403 instead compare against just the index cache contents, and ignore the

404 current working tree state entirely. Since we just wrote the index

405 -file to HEAD, doing `git diff-index \--cached -p HEAD` should thus return

405 +file to HEAD, doing `git diff-index --cached -p HEAD` should thus return

406 an empty set of differences, and that's exactly what it does.

407

408 [NOTE]

@@ -411,7 +411,7 @@ an empty set of differences, and that's exactly what it does.

411 comparisons, and saying that it compares a tree against the working

412 tree is thus not strictly accurate. In particular, the list of

413 files to compare (the "meta-data") *always* comes from the index file,

414 -regardless of whether the `\--cached` flag is used or not. The `\--cached`

414 +regardless of whether the `--cached` flag is used or not. The `--cached`

415 flag really only determines whether the file *contents* to be compared

416 come from the working tree or not.

417

@@ -433,7 +433,7 @@ update the index cache:

433 $ git update-index hello

434 ------------------------------------------------

435

436 -(note how we didn't need the `\--add` flag this time, since git knew

436 +(note how we didn't need the `--add` flag this time, since git knew

437 about the file already).

438

439 Note what happens to the different 'git diff-{asterisk}' versions here.

@@ -560,7 +560,7 @@ short history.

560 When using the above two commands, the initial commit will be shown.

561 If this is a problem because it is huge, you can hide it by setting

562 the log.showroot configuration variable to false. Having this, you

563 -can still show it for each command just adding the `\--root` option,

563 +can still show it for each command just adding the `--root` option,

564 which is a flag for 'git diff-tree' accepted by both commands.

565

566 With that, you should now be having some inkling of what git does, and

@@ -881,7 +881,7 @@ helps you view what's going on:

881 $ gitk --all

882 ----------------

883

884 -will show you graphically both of your branches (that's what the `\--all`

884 +will show you graphically both of your branches (that's what the `--all`

885 means: normally it will just show you your current `HEAD`) and their

886 histories. You can also see exactly how they came to be from a common

887 source.

@@ -935,7 +935,7 @@ which will very loudly warn you that you're now committing a merge

935 (which is correct, so never mind), and you can write a small merge

936 message about your adventures in 'git merge'-land.

937

938 -After you're done, start up `gitk \--all` to see graphically what the

938 +After you're done, start up `gitk --all` to see graphically what the

939 history looks like. Notice that `mybranch` still exists, and you can

940 switch to it, and continue to work with it if you want to. The

941 `mybranch` branch will not contain the merge, but next time you merge it

@@ -958,11 +958,11 @@ $ git show-branch --topo-order --more=1 master mybranch

958 The first two lines indicate that it is showing the two branches

959 and the first line of the commit log message from their

960 top-of-the-tree commits, you are currently on `master` branch

961 -(notice the asterisk `{asterisk}` character), and the first column for

961 +(notice the asterisk `*` character), and the first column for

962 the later output lines is used to show commits contained in the

963 `master` branch, and the second column for the `mybranch`

964 branch. Three commits are shown along with their log messages.

965 -All of them have non blank characters in the first column (`{asterisk}`

965 +All of them have non blank characters in the first column (`*`

966 shows an ordinary commit on the current branch, `-` is a merge commit), which

967 means they are now part of the `master` branch. Only the "Some

968 work" commit has the plus `+` character in the second column,

@@ -1013,7 +1013,7 @@ not actually do a merge. Instead, it just updated the top of

1013 the tree of your branch to that of the `master` branch. This is

1014 often called 'fast-forward' merge.

1015

1016 -You can run `gitk \--all` again to see how the commit ancestry

1016 +You can run `gitk --all` again to see how the commit ancestry

1017 looks like, or run 'show-branch', which tells you this.

1018

1019 ------------------------------------------------

@@ -1257,7 +1257,7 @@ this 'collapsing' tends to trivially merge most of the paths

1257 fairly quickly, leaving only a handful of real changes in non-zero

1258 stages.

1259

1260 -To look at only non-zero stages, use `\--unmerged` flag:

1260 +To look at only non-zero stages, use `--unmerged` flag:

1261

1262 ------------

1263 $ git ls-files --unmerged

@@ -1420,7 +1420,7 @@ packed, and stores the packed file in `.git/objects/pack`

1420 directory.

1421

1422 [NOTE]

1423 -You will see two files, `pack-{asterisk}.pack` and `pack-{asterisk}.idx`,

1423 +You will see two files, `pack-*.pack` and `pack-*.idx`,

1424 in `.git/objects/pack` directory. They are closely related to

1425 each other, and if you ever copy them by hand to a different

1426 repository for whatever reason, you should make sure you copy

Documentation/gitcredentials.txt

+2 -2

@@ -143,8 +143,8 @@ CONFIGURATION OPTIONS

143 ---------------------

144

145 Options for a credential context can be configured either in

146 -`credential.\*` (which applies to all credentials), or

147 -`credential.<url>.\*`, where <url> matches the context as described

146 +`credential.*` (which applies to all credentials), or

147 +`credential.<url>.*`, where <url> matches the context as described

148 above.

149

150 The following options are available in either location:

Documentation/gitdiffcore.txt

+5 -5

@@ -168,11 +168,11 @@ a similarity score different from the default of 50% by giving a

168 number after the "-M" or "-C" option (e.g. "-M8" to tell it to use

169 8/10 = 80%).

170

171 -Note. When the "-C" option is used with `\--find-copies-harder`

171 +Note. When the "-C" option is used with `--find-copies-harder`

172 option, 'git diff-{asterisk}' commands feed unmodified filepairs to

173 diffcore mechanism as well as modified ones. This lets the copy

174 detector consider unmodified files as copy source candidates at

175 -the expense of making it slower. Without `\--find-copies-harder`,

175 +the expense of making it slower. Without `--find-copies-harder`,

176 'git diff-{asterisk}' commands can detect copies only if the file that was

177 copied happened to have been modified in the same changeset.

178

@@ -224,7 +224,7 @@ diffcore-pickaxe: For Detecting Addition/Deletion of Specified String

224

225 This transformation is used to find filepairs that represent

226 changes that touch a specified string, and is controlled by the

227 --S option and the `\--pickaxe-all` option to the 'git diff-{asterisk}'

227 +-S option and the `--pickaxe-all` option to the 'git diff-*'

228 commands.

229

230 When diffcore-pickaxe is in use, it checks if there are

@@ -233,9 +233,9 @@ different number of specified string. Such a filepair represents

233 "the string appeared in this changeset". It also checks for the

234 opposite case that loses the specified string.

235

236 -When `\--pickaxe-all` is not in effect, diffcore-pickaxe leaves

236 +When `--pickaxe-all` is not in effect, diffcore-pickaxe leaves

237 only such filepairs that touch the specified string in its

238 -output. When `\--pickaxe-all` is used, diffcore-pickaxe leaves all

238 +output. When `--pickaxe-all` is used, diffcore-pickaxe leaves all

239 filepairs intact if there is such a filepair, or makes the

240 output empty otherwise. The latter behaviour is designed to

241 make reviewing of the changes in the context of the whole

Documentation/githooks.txt

+4 -4

@@ -73,7 +73,7 @@ pre-commit

73 ~~~~~~~~~~

74

75 This hook is invoked by 'git commit', and can be bypassed

76 -with `\--no-verify` option. It takes no parameter, and is

76 +with `--no-verify` option. It takes no parameter, and is

77 invoked before obtaining the proposed commit log message and

78 making a commit. Exiting with non-zero status from this script

79 causes the 'git commit' to abort.

@@ -99,12 +99,12 @@ given); `template` (if a `-t` option was given or the

99 configuration option `commit.template` is set); `merge` (if the

100 commit is a merge or a `.git/MERGE_MSG` file exists); `squash`

101 (if a `.git/SQUASH_MSG` file exists); or `commit`, followed by

102 -a commit SHA1 (if a `-c`, `-C` or `\--amend` option was given).

102 +a commit SHA1 (if a `-c`, `-C` or `--amend` option was given).

103

104 If the exit status is non-zero, 'git commit' will abort.

105

106 The purpose of the hook is to edit the message file in place, and

107 -it is not suppressed by the `\--no-verify` option. A non-zero exit

107 +it is not suppressed by the `--no-verify` option. A non-zero exit

108 means a failure of the hook and aborts the commit. It should not

109 be used as replacement for pre-commit hook.

110

@@ -115,7 +115,7 @@ commit-msg

115 ~~~~~~~~~~

116

117 This hook is invoked by 'git commit', and can be bypassed

118 -with `\--no-verify` option. It takes a single parameter, the

118 +with `--no-verify` option. It takes a single parameter, the

119 name of the file that holds the proposed commit log message.

120 Exiting with non-zero status causes the 'git commit' to

121 abort.

Documentation/gitweb.conf.txt

+6 -6

@@ -749,14 +749,14 @@ Project specific override is not supported.

749 forks::

750 If this feature is enabled, gitweb considers projects in

751 subdirectories of project root (basename) to be forks of existing

752 - projects. For each project `$projname.git`, projects in the

753 - `$projname/` directory and its subdirectories will not be

754 - shown in the main projects list. Instead, a \'+' mark is shown

755 - next to `$projname`, which links to a "forks" view that lists all

756 - the forks (all projects in `$projname/` subdirectory). Additionally

752 + projects. For each project +$projname.git+, projects in the

753 + +$projname/+ directory and its subdirectories will not be

754 + shown in the main projects list. Instead, a \'\+' mark is shown

755 + next to +$projname+, which links to a "forks" view that lists all

756 + the forks (all projects in +$projname/+ subdirectory). Additionally

757 a "forks" view for a project is linked from project summary page.

758 +

759 -If the project list is taken from a file (`$projects_list` points to a

759 +If the project list is taken from a file (+$projects_list+ points to a

760 file), forks are only recognized if they are listed after the main project

761 in that file.

762 +

Documentation/gitworkflows.txt

+2 -2

@@ -39,8 +39,8 @@ To achieve this, try to split your work into small steps from the very

39 beginning. It is always easier to squash a few commits together than

40 to split one big commit into several. Don't be afraid of making too

41 small or imperfect steps along the way. You can always go back later

42 -and edit the commits with `git rebase \--interactive` before you

43 -publish them. You can use `git stash save \--keep-index` to run the

42 +and edit the commits with `git rebase --interactive` before you

43 +publish them. You can use `git stash save --keep-index` to run the

44 test suite independent of other uncommitted changes; see the EXAMPLES

45 section of linkgit:git-stash[1].

46

Documentation/pretty-formats.txt

+3 -3

@@ -130,8 +130,8 @@ The placeholders are:

130 - '%b': body

131 - '%B': raw body (unwrapped subject and body)

132 - '%N': commit notes

133 -- '%gD': reflog selector, e.g., `refs/stash@\{1\}`

134 -- '%gd': shortened reflog selector, e.g., `stash@\{1\}`

133 +- '%gD': reflog selector, e.g., `refs/stash@{1}`

134 +- '%gd': shortened reflog selector, e.g., `stash@{1}`

135 - '%gn': reflog identity name

136 - '%gN': reflog identity name (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1])

137 - '%ge': reflog identity email

@@ -155,7 +155,7 @@ insert an empty string unless we are traversing reflog entries (e.g., by

155 `git log -g`). The `%d` placeholder will use the "short" decoration

156 format if `--decorate` was not already provided on the command line.

157

158 -If you add a `{plus}` (plus sign) after '%' of a placeholder, a line-feed

158 +If you add a `+` (plus sign) after '%' of a placeholder, a line-feed

159 is inserted immediately before the expansion if and only if the

160 placeholder expands to a non-empty string.

161

Documentation/pull-fetch-param.txt

+1 -1

@@ -13,7 +13,7 @@ endif::git-pull[]

13

14 <refspec>::

15 The format of a <refspec> parameter is an optional plus

16 - `{plus}`, followed by the source ref <src>, followed

16 + `+`, followed by the source ref <src>, followed

17 by a colon `:`, followed by the destination ref <dst>.

18 +

19 The remote ref that matches <src>

Documentation/rev-list-options.txt

+3 -3

@@ -198,7 +198,7 @@ excluded from the output.

198 +

199 For example, `--cherry-pick --right-only A...B` omits those

200 commits from `B` which are in `A` or are patch-equivalent to a commit in

201 -`A`. In other words, this lists the `{plus}` commits from `git cherry A B`.

201 +`A`. In other words, this lists the `+` commits from `git cherry A B`.

202 More precisely, `--cherry-pick --right-only --no-merges` gives the exact

203 list.

204

@@ -455,7 +455,7 @@ The effect of this is best shown by way of comparing to

455 `---------'

456 -----------------------------------------------------------------------

457 +

458 -Note the major differences in `N` and `P` over '\--full-history':

458 +Note the major differences in `N` and `P` over '--full-history':

459 +

460 --

461 * `N`'s parent list had `I` removed, because it is an ancestor of the

@@ -494,7 +494,7 @@ of course).

494 When we want to find out what commits in `M` are contaminated with the

495 bug introduced by `D` and need fixing, however, we might want to view

496 only the subset of 'D..M' that are actually descendants of `D`, i.e.

497 -excluding `C` and `K`. This is exactly what the '\--ancestry-path'

497 +excluding `C` and `K`. This is exactly what the '--ancestry-path'

498 option does. Applied to the 'D..M' range, it results in:

499 +

500 -----------------------------------------------------------------------

Documentation/technical/api-parse-options.txt

+18 -18

@@ -21,7 +21,7 @@ that allow to change the behavior of a command.

21 * There are basically two forms of options:

22 'Short options' consist of one dash (`-`) and one alphanumeric

23 character.

24 - 'Long options' begin with two dashes (`\--`) and some

24 + 'Long options' begin with two dashes (`--`) and some

25 alphanumeric characters.

26

27 * Options are case-sensitive.

@@ -31,7 +31,7 @@ The parse-options API allows:

31

32 * 'sticked' and 'separate form' of options with arguments.

33 `-oArg` is sticked, `-o Arg` is separate form.

34 - `\--option=Arg` is sticked, `\--option Arg` is separate form.

34 + `--option=Arg` is sticked, `--option Arg` is separate form.

35

36 * Long options may be 'abbreviated', as long as the abbreviation

37 is unambiguous.

@@ -39,12 +39,12 @@ The parse-options API allows:

39 * Short options may be bundled, e.g. `-a -b` can be specified as `-ab`.

40

41 * Boolean long options can be 'negated' (or 'unset') by prepending

42 - `no-`, e.g. `\--no-abbrev` instead of `\--abbrev`. Conversely,

42 + `no-`, e.g. `--no-abbrev` instead of `--abbrev`. Conversely,

43 options that begin with `no-` can be 'negated' by removing it.

44

45 -* Options and non-option arguments can clearly be separated using the `\--`

46 - option, e.g. `-a -b \--option \-- \--this-is-a-file` indicates that

47 - `\--this-is-a-file` must not be processed as an option.

45 +* Options and non-option arguments can clearly be separated using the `--`

46 + option, e.g. `-a -b --option -- --this-is-a-file` indicates that

47 + `--this-is-a-file` must not be processed as an option.

48

49 Steps to parse options

50 ----------------------

@@ -76,7 +76,7 @@ before the full parser, which in turn shows the full help message.

76 Flags are the bitwise-or of:

77

78 `PARSE_OPT_KEEP_DASHDASH`::

79 - Keep the `\--` that usually separates options from

79 + Keep the `--` that usually separates options from

80 non-option arguments.

81

82 `PARSE_OPT_STOP_AT_NON_OPTION`::

@@ -114,22 +114,22 @@ say `static struct option builtin_add_options[]`.

114 There are some macros to easily define options:

115

116 `OPT__ABBREV(&int_var)`::

117 - Add `\--abbrev[=<n>]`.

117 + Add `--abbrev[=<n>]`.

118

119 `OPT__COLOR(&int_var, description)`::

120 - Add `\--color[=<when>]` and `--no-color`.

120 + Add `--color[=<when>]` and `--no-color`.

121

122 `OPT__DRY_RUN(&int_var, description)`::

123 - Add `-n, \--dry-run`.

123 + Add `-n, --dry-run`.

124

125 `OPT__FORCE(&int_var, description)`::

126 - Add `-f, \--force`.

126 + Add `-f, --force`.

127

128 `OPT__QUIET(&int_var, description)`::

129 - Add `-q, \--quiet`.

129 + Add `-q, --quiet`.

130

131 `OPT__VERBOSE(&int_var, description)`::

132 - Add `-v, \--verbose`.

132 + Add `-v, --verbose`.

133

134 `OPT_GROUP(description)`::

135 Start an option group. `description` is a short string that

@@ -216,10 +216,10 @@ The last element of the array must be `OPT_END()`.

216 If not stated otherwise, interpret the arguments as follows:

217

218 * `short` is a character for the short option

219 - (e.g. `{apostrophe}e{apostrophe}` for `-e`, use `0` to omit),

219 + (e.g. `'e'` for `-e`, use `0` to omit),

220

221 * `long` is a string for the long option

222 - (e.g. `"example"` for `\--example`, use `NULL` to omit),

222 + (e.g. `"example"` for `--example`, use `NULL` to omit),

223

224 * `int_var` is an integer variable,

225

@@ -243,10 +243,10 @@ The function must be defined in this form:

243 The callback mechanism is as follows:

244

245 * Inside `func`, the only interesting member of the structure

246 - given by `opt` is the void pointer `opt\->value`.

247 - `\*opt\->value` will be the value that is saved into `var`, if you

246 + given by `opt` is the void pointer `opt->value`.

247 + `*opt->value` will be the value that is saved into `var`, if you

248 use `OPT_CALLBACK()`.

249 - For example, do `*(unsigned long *)opt\->value = 42;` to get 42

249 + For example, do `*(unsigned long *)opt->value = 42;` to get 42

250 into an `unsigned long` variable.

251

252 * Return value `0` indicates success and non-zero return

Documentation/technical/protocol-common.txt

+1 -1

@@ -36,7 +36,7 @@ More specifically, they:

36

37 . They cannot have ASCII control characters (i.e. bytes whose

38 values are lower than \040, or \177 `DEL`), space, tilde `~`,

39 - caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,

39 + caret `^`, colon `:`, question-mark `?`, asterisk `*`,

40 or open bracket `[` anywhere.

41

42 . They cannot end with a slash `/` nor a dot `.`.

Documentation/user-manual.txt

+4 -4

@@ -1611,7 +1611,7 @@ Recovering lost changes

1611 Reflogs

1612 ^^^^^^^

1613

1614 -Say you modify a branch with `linkgit:git-reset[1] --hard`, and then

1614 +Say you modify a branch with +linkgit:git-reset[1] \--hard+, and then

1615 realize that the branch was the only reference you had to that point in

1616 history.

1617

@@ -4207,7 +4207,7 @@ commits one by one with the function `get_revision()`.

4207

4208 If you are interested in more details of the revision walking process,

4209 just have a look at the first implementation of `cmd_log()`; call

4210 -`git show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you

4210 +`git show v1.3.0~155^2~4` and scroll down to that function (note that you

4211 no longer need to call `setup_pager()` directly).

4212

4213 Nowadays, `git log` is a builtin, which means that it is _contained_ in the

@@ -4270,9 +4270,9 @@ Two things are interesting here:

4270 negative numbers in case of different errors--and 0 on success.

4271

4272 - the variable `sha1` in the function signature of `get_sha1()` is `unsigned

4273 - char {asterisk}`, but is actually expected to be a pointer to `unsigned

4273 + char *`, but is actually expected to be a pointer to `unsigned

4274 char[20]`. This variable will contain the 160-bit SHA-1 of the given

4275 - commit. Note that whenever a SHA-1 is passed as `unsigned char {asterisk}`, it

4275 + commit. Note that whenever a SHA-1 is passed as `unsigned char *`, it

4276 is the binary representation, as opposed to the ASCII representation in

4277 hex characters, which is passed as `char *`.

4278

docs: stop using asciidoc no-inline-literal