@matheusbsbs / matheus-bagliano / commits / dcb11263bc

Fork 0

Documentation: remove extra quoting/emphasis around literal texts

If literal text (asciidoc `...`) can be rendered in a differently from normal text for each output format (man, HTML), then we do not need extra quotes or other wrapping around inline literal text segments. config.txt Change '`...`' to `...`. In asciidoc, the single quotes provide emphasis, literal text should be distintive enough. Change "`...`" to `...`. These double quotes do not work if present in the described config value, so drop them. git-checkout.txt Change "`...`" to `...` or `"..."`. All instances are command line argument examples. One "`-`" becomes `-`. Two others are involve curly braces, so move the double quotes inside the literal region to indicate that they might need to be quoted on the command line of certain shells (tcsh). git-merge.txt Change "`...`" to `...`. All instances are used to describe merge conflict markers. The quotes should are not important. git-rev-parse.txt Change "`...`" to `...`. All instances are around command line arguments where no in-shell quoting should be necessary. gitcli.txt Change `"..."` to `...`. All instances are around command line examples or single command arguments. They do not semanticly belong inside the literal text, and they are not needed outside it. glossary-content.txt user-manual.txt Change "`...`" to `...`. All instances were around command lines. Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Chris Johnsen committed Mar 15, 2009 at 06:30 UTC dcb11263bcdbf31955dd00777392249bf1624226

7 files changed +37 -37

Documentation/config.txt

+12 -12

@@ -25,7 +25,7 @@ blank lines are ignored.

25 The file consists of sections and variables. A section begins with

26 the name of the section in square brackets and continues until the next

27 section begins. Section names are not case sensitive. Only alphanumeric

28 -characters, '`-`' and '`.`' are allowed in section names. Each variable

28 +characters, `-` and `.` are allowed in section names. Each variable

29 must belong to some section, which means that there must be section

30 header before first setting of a variable.

@@ -39,7 +39,7 @@ in the section header, like in example below:

39 --------

41 Subsection names can contain any characters except newline (doublequote

42 -'`"`' and backslash have to be escaped as '`\"`' and '`\\`',

42 +`"` and backslash have to be escaped as `\"` and `\\`,

43 respectively) and are case sensitive. Section header cannot span multiple

44 lines. Variables may belong directly to a section or to a given subsection.

45 You can have `[section]` if you have `[section "subsection"]`, but you

@@ -53,7 +53,7 @@ All the other lines are recognized as setting variables, in the form

53 'name = value'. If there is no equal sign on the line, the entire line

54 is taken as 'name' and the variable is recognized as boolean "true".

55 The variable names are case-insensitive and only alphanumeric

56 -characters and '`-`' are allowed. There can be more than one value

56 +characters and `-` are allowed. There can be more than one value

57 for a given variable; we say then that variable is multivalued.

59 Leading and trailing whitespace in a variable value is discarded.

@@ -69,15 +69,15 @@ String values may be entirely or partially enclosed in double quotes.

69 You need to enclose variable value in double quotes if you want to

70 preserve leading or trailing whitespace, or if variable value contains

71 beginning of comment characters (if it contains '#' or ';').

72 -Double quote '`"`' and backslash '`\`' characters in variable value must

73 -be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'.

72 +Double quote `"` and backslash `\` characters in variable value must

73 +be escaped: use `\"` for `"` and `\\` for `\`.

75 -The following escape sequences (beside '`\"`' and '`\\`') are recognized:

76 -'`\n`' for newline character (NL), '`\t`' for horizontal tabulation (HT, TAB)

77 -and '`\b`' for backspace (BS). No other char escape sequence, nor octal

75 +The following escape sequences (beside `\"` and `\\`) are recognized:

76 +`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)

77 +and `\b` for backspace (BS). No other char escape sequence, nor octal

78 char sequences are valid.

80 -Variable value ending in a '`\`' is continued on the next line in the

80 +Variable value ending in a `\` is continued on the next line in the

81 customary UNIX fashion.

83 Some variables may require special value format.

@@ -382,9 +382,9 @@ core.pager::

382 to override git's default settings this way, you need

383 to be explicit. For example, to disable the S option

384 in a backward compatible manner, set `core.pager`

385 - to "`less -+$LESS -FRX`". This will be passed to the

385 + to `less -+$LESS -FRX`. This will be passed to the

386 shell by git, which will translate the final command to

387 - "`LESS=FRSX less -+FRSX -FRX`".

387 + `LESS=FRSX less -+FRSX -FRX`.

388

389 core.whitespace::

390 A comma separated list of common whitespace problems to

@@ -1161,7 +1161,7 @@ pager.<cmd>::

1161 particular git subcommand when writing to a tty. If

1162 `\--paginate` or `\--no-pager` is specified on the command line,

1163 it takes precedence over this option. To disable pagination for

1164 - all commands, set `core.pager` or 'GIT_PAGER' to "`cat`".

1164 + all commands, set `core.pager` or `GIT_PAGER` to `cat`.

1165

1166 pull.octopus::

1167 The default merge strategy to use when pulling multiple branches

Documentation/git-checkout.txt

+2 -2

@@ -133,9 +133,9 @@ the conflicted merge in the specified paths.

133 When this parameter names a non-branch (but still a valid commit object),

134 your HEAD becomes 'detached'.

135 +

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

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

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

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

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

139

140

141 Detached HEAD

Documentation/git-merge.txt

+3 -3

@@ -146,7 +146,7 @@ And here is another line that is cleanly resolved or unmodified.

146 ------------

147

148 The area where a pair of conflicting changes happened is marked with markers

149 -"`<<<<<<<`", "`=======`", and "`>>>>>>>`". The part before the "`=======`"

149 +`<<<<<<<`, `=======`, and `>>>>>>>`. The part before the `=======`

150 is typically your side, and the part afterwards is typically their side.

151

152 The default format does not show what the original said in the conflicting

@@ -173,8 +173,8 @@ Git makes conflict resolution easy.

173 And here is another line that is cleanly resolved or unmodified.

174 ------------

175

176 -In addition to the "`<<<<<<<`", "`=======`", and "`>>>>>>>`" markers, it uses

177 -another "`|||||||`" marker that is followed by the original text. You can

176 +In addition to the `<<<<<<<`, `=======`, and `>>>>>>>` markers, it uses

177 +another `|||||||` marker that is followed by the original text. You can

178 tell that the original just stated a fact, and your side simply gave in to

179 that statement and gave up, while the other side tried to have a more

180 positive attitude. You can sometimes come up with a better resolution by

Documentation/git-rev-parse.txt

+4 -4

@@ -299,18 +299,18 @@ previous section means the set of commits reachable from that

299 commit, following the commit ancestry chain.

300

301 To exclude commits reachable from a commit, a prefix `{caret}`

302 -notation is used. E.g. "`{caret}r1 r2`" means commits reachable

302 +notation is used. E.g. `{caret}r1 r2` means commits reachable

303 from `r2` but exclude the ones reachable from `r1`.

304

305 This set operation appears so often that there is a shorthand

306 for it. When you have two commits `r1` and `r2` (named according

307 to the syntax explained in SPECIFYING REVISIONS above), you can ask

308 for commits that are reachable from r2 excluding those that are reachable

309 -from r1 by "`{caret}r1 r2`" and it can be written as "`r1..r2`".

309 +from r1 by `{caret}r1 r2` and it can be written as `r1..r2`.

310

311 -A similar notation "`r1\...r2`" is called symmetric difference

311 +A similar notation `r1\...r2` is called symmetric difference

312 of `r1` and `r2` and is defined as

313 -"`r1 r2 --not $(git merge-base --all r1 r2)`".

313 +`r1 r2 --not $(git merge-base --all r1 r2)`.

314 It is the set of commits that are reachable from either one of

315 `r1` or `r2` but not from both.

316

Documentation/gitcli.txt

+12 -12

@@ -46,20 +46,20 @@ Here are the rules regarding the "flags" that you should follow when you are

46 scripting git:

48 * it's preferred to use the non dashed form of git commands, which means that

49 - you should prefer `"git foo"` to `"git-foo"`.

49 + you should prefer `git foo` to `git-foo`.

51 - * splitting short options to separate words (prefer `"git foo -a -b"`

52 - to `"git foo -ab"`, the latter may not even work).

51 + * splitting short options to separate words (prefer `git foo -a -b`

52 + to `git foo -ab`, the latter may not even work).

54 * when a command line option takes an argument, use the 'sticked' form. In

55 - other words, write `"git foo -oArg"` instead of `"git foo -o Arg"` for short

56 - options, and `"git foo --long-opt=Arg"` instead of `"git foo --long-opt Arg"`

55 + other words, write `git foo -oArg` instead of `git foo -o Arg` for short

56 + options, and `git foo --long-opt=Arg` instead of `git foo --long-opt Arg`

57 for long options. An option that takes optional option-argument must be

58 written in the 'sticked' form.

60 * when you give a revision parameter to a command, make sure the parameter is

61 not ambiguous with a name of a file in the work tree. E.g. do not write

62 - `"git log -1 HEAD"` but write `"git log -1 HEAD --"`; the former will not work

62 + `git log -1 HEAD` but write `git log -1 HEAD --`; the former will not work

63 if you happen to have a file called `HEAD` in the work tree.

@@ -99,17 +99,17 @@ usage: git-describe [options] <committish>*

100 Negating options

101 ~~~~~~~~~~~~~~~~

102 -Options with long option names can be negated by prefixing `"--no-"`. For

103 -example, `"git branch"` has the option `"--track"` which is 'on' by default. You

104 -can use `"--no-track"` to override that behaviour. The same goes for `"--color"`

105 -and `"--no-color"`.

102 +Options with long option names can be negated by prefixing `--no-`. For

103 +example, `git branch` has the option `--track` which is 'on' by default. You

104 +can use `--no-track` to override that behaviour. The same goes for `--color`

105 +and `--no-color`.

106

107

108 Aggregating short options

109 ~~~~~~~~~~~~~~~~~~~~~~~~~

110 Commands that support the enhanced option parser allow you to aggregate short

111 -options. This means that you can for example use `"git rm -rf"` or

112 -`"git clean -fdx"`.

111 +options. This means that you can for example use `git rm -rf` or

112 +`git clean -fdx`.

113

114

115 Separating argument from the option

Documentation/glossary-content.txt

+1 -1

@@ -262,7 +262,7 @@ This commit is referred to as a "merge commit", or sometimes just a

262 'origin' is used for that purpose. New upstream updates

263 will be fetched into remote <<def_tracking_branch,tracking branches>> named

264 origin/name-of-upstream-branch, which you can see using

265 - "`git branch -r`".

265 + `git branch -r`.

266

267 [[def_pack]]pack::

268 A set of objects which have been compressed into one file (to save space

Documentation/user-manual.txt

+3 -3

@@ -1136,10 +1136,10 @@ Ignoring files

1136 A project will often generate files that you do 'not' want to track with git.

1137 This typically includes files generated by a build process or temporary

1138 backup files made by your editor. Of course, 'not' tracking files with git

1139 -is just a matter of 'not' calling "`git-add`" on them. But it quickly becomes

1139 +is just a matter of 'not' calling `git-add` on them. But it quickly becomes

1140 annoying to have these untracked files lying around; e.g. they make

1141 -"`git add .`" practically useless, and they keep showing up in the output of

1142 -"`git status`".

1141 +`git add .` practically useless, and they keep showing up in the output of

1142 +`git status`.

1143

1144 You can tell git to ignore certain files by creating a file called .gitignore

1145 in the top level of your working directory, with contents such as: