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>

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 56bd781a163d70ce23f1b6932ce3b1c70510d3b5..70fd172c6b20613a6893db2fe0f2183482f8b926 100644 (file)
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -25,7 +25,7 @@ blank lines are ignored.
 The file consists of sections and variables.  A section begins with
 the name of the section in square brackets and continues until the next
 section begins.  Section names are not case sensitive.  Only alphanumeric
 The file consists of sections and variables.  A section begins with
 the name of the section in square brackets and continues until the next
 section begins.  Section names are not case sensitive.  Only alphanumeric

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

 must belong to some section, which means that there must be section
 header before first setting of a variable.
 
 must belong to some section, which means that there must be section
 header before first setting of a variable.
 


@@ -39,7 +39,7 @@ in the section header, like in example below:
 --------
 
 Subsection names can contain any characters except newline (doublequote
 --------
 
 Subsection names can contain any characters except newline (doublequote

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

 respectively) and are case sensitive.  Section header cannot span multiple
 lines.  Variables may belong directly to a section or to a given subsection.
 You can have `[section]` if you have `[section "subsection"]`, but you
 respectively) and are case sensitive.  Section header cannot span multiple
 lines.  Variables may belong directly to a section or to a given subsection.
 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
 'name = value'.  If there is no equal sign on the line, the entire line
 is taken as 'name' and the variable is recognized as boolean "true".
 The variable names are case-insensitive and only alphanumeric
 'name = value'.  If there is no equal sign on the line, the entire line
 is taken as 'name' and the variable is recognized as boolean "true".
 The variable names are case-insensitive and only alphanumeric

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

 for a given variable; we say then that variable is multivalued.
 
 Leading and trailing whitespace in a variable value is discarded.
 for a given variable; we say then that variable is multivalued.
 
 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.
 You need to enclose variable value in double quotes if you want to
 preserve leading or trailing whitespace, or if variable value contains
 beginning of comment characters (if it contains '#' or ';').
 You need to enclose variable value in double quotes if you want to
 preserve leading or trailing whitespace, or if variable value contains
 beginning of comment characters (if it contains '#' or ';').

-Double quote '`"`' and backslash '`\`' characters in variable value must
-be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'.
+Double quote `"` and backslash `\` characters in variable value must
+be escaped: use `\"` for `"` and `\\` for `\`.

 
 

-The following escape sequences (beside '`\"`' and '`\\`') are recognized:
-'`\n`' for newline character (NL), '`\t`' for horizontal tabulation (HT, TAB)
-and '`\b`' for backspace (BS).  No other char escape sequence, nor octal
+The following escape sequences (beside `\"` and `\\`) are recognized:
+`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
+and `\b` for backspace (BS).  No other char escape sequence, nor octal

 char sequences are valid.
 
 char sequences are valid.
 

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

 customary UNIX fashion.
 
 Some variables may require special value format.
 customary UNIX fashion.
 
 Some variables may require special value format.


@@ -382,9 +382,9 @@ core.pager::
        to override git's default settings this way, you need
        to be explicit.  For example, to disable the S option
        in a backward compatible manner, set `core.pager`
        to override git's default settings this way, you need
        to be explicit.  For example, to disable the S option
        in a backward compatible manner, set `core.pager`

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

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

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

 
 core.whitespace::
        A comma separated list of common whitespace problems to
 
 core.whitespace::
        A comma separated list of common whitespace problems to


@@ -1161,7 +1161,7 @@ pager.<cmd>::
        particular git subcommand when writing to a tty.  If
        `\--paginate` or `\--no-pager` is specified on the command line,
        it takes precedence over this option.  To disable pagination for
        particular git subcommand when writing to a tty.  If
        `\--paginate` or `\--no-pager` is specified on the command line,
        it takes precedence over this option.  To disable pagination for

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

 
 pull.octopus::
        The default merge strategy to use when pulling multiple branches
 
 pull.octopus::
        The default merge strategy to use when pulling multiple branches

diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 125d8f3c32470cd0917bade45ed7e9fcd7f4c376..1a6c19e5c39ad038e3fa073926683a21d7c21935 100644 (file)
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -133,9 +133,9 @@ the conflicted merge in the specified paths.
 When this parameter names a non-branch (but still a valid commit object),
 your HEAD becomes 'detached'.
 +
 When this parameter names a non-branch (but still a valid commit object),
 your HEAD becomes 'detached'.
 +

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

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

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

 
 
 Detached HEAD
 
 
 Detached HEAD

diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index f7be5846a67de1a3215bad3d7b9c263705cd1bba..cc0d30fe7e6c96d25304181ef2fdd9cbd02e7817 100644 (file)
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -146,7 +146,7 @@ And here is another line that is cleanly resolved or unmodified.
 ------------
 
 The area where a pair of conflicting changes happened is marked with markers
 ------------
 
 The area where a pair of conflicting changes happened is marked with markers

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

 is typically your side, and the part afterwards is typically their side.
 
 The default format does not show what the original said in the conflicting
 is typically your side, and the part afterwards is typically their side.
 
 The default format does not show what the original said in the conflicting


@@ -173,8 +173,8 @@ Git makes conflict resolution easy.
 And here is another line that is cleanly resolved or unmodified.
 ------------
 
 And here is another line that is cleanly resolved or unmodified.
 ------------
 

-In addition to the "`<<<<<<<`", "`=======`", and "`>>>>>>>`" markers, it uses
-another "`|||||||`" marker that is followed by the original text.  You can
+In addition to the `<<<<<<<`, `=======`, and `>>>>>>>` markers, it uses
+another `|||||||` marker that is followed by the original text.  You can

 tell that the original just stated a fact, and your side simply gave in to
 that statement and gave up, while the other side tried to have a more
 positive attitude.  You can sometimes come up with a better resolution by
 tell that the original just stated a fact, and your side simply gave in to
 that statement and gave up, while the other side tried to have a more
 positive attitude.  You can sometimes come up with a better resolution by

diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 3ccef2f2b3295c6d5e14b8f3a9d354d7b57598da..5ed2bc840f962cfe3af6bf4540edf46f47b9e148 100644 (file)
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -299,18 +299,18 @@ previous section means the set of commits reachable from that
 commit, following the commit ancestry chain.
 
 To exclude commits reachable from a commit, a prefix `{caret}`
 commit, following the commit ancestry chain.
 
 To exclude commits reachable from a commit, a prefix `{caret}`

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

 from `r2` but exclude the ones reachable from `r1`.
 
 This set operation appears so often that there is a shorthand
 for it.  When you have two commits `r1` and `r2` (named according
 to the syntax explained in SPECIFYING REVISIONS above), you can ask
 for commits that are reachable from r2 excluding those that are reachable
 from `r2` but exclude the ones reachable from `r1`.
 
 This set operation appears so often that there is a shorthand
 for it.  When you have two commits `r1` and `r2` (named according
 to the syntax explained in SPECIFYING REVISIONS above), you can ask
 for commits that are reachable from r2 excluding those that are reachable

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

 
 

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

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

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

 It is the set of commits that are reachable from either one of
 `r1` or `r2` but not from both.
 
 It is the set of commits that are reachable from either one of
 `r1` or `r2` but not from both.
 

diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index 29e5929db22257346a2bed16cbd5ca6531698676..be39ed7c1509158867998ce8fb77341242ecdf79 100644 (file)
--- a/Documentation/gitcli.txt
+++ b/Documentation/gitcli.txt
@@ -46,20 +46,20 @@ Here are the rules regarding the "flags" that you should follow when you are
 scripting git:
 
  * it's preferred to use the non dashed form of git commands, which means that
 scripting git:
 
  * it's preferred to use the non dashed form of git commands, which means that

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

 
 

- * splitting short options to separate words (prefer `"git foo -a -b"`
-   to `"git foo -ab"`, the latter may not even work).
+ * splitting short options to separate words (prefer `git foo -a -b`
+   to `git foo -ab`, the latter may not even work).

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

-   other words, write `"git foo -oArg"` instead of `"git foo -o Arg"` for short
-   options, and `"git foo --long-opt=Arg"` instead of `"git foo --long-opt Arg"`
+   other words, write `git foo -oArg` instead of `git foo -o Arg` for short
+   options, and `git foo --long-opt=Arg` instead of `git foo --long-opt Arg`

    for long options.  An option that takes optional option-argument must be
    written in the 'sticked' form.
 
  * when you give a revision parameter to a command, make sure the parameter is
    not ambiguous with a name of a file in the work tree.  E.g. do not write
    for long options.  An option that takes optional option-argument must be
    written in the 'sticked' form.
 
  * when you give a revision parameter to a command, make sure the parameter is
    not ambiguous with a name of a file in the work tree.  E.g. do not write

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

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


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

-Options with long option names can be negated by prefixing `"--no-"`. For
-example, `"git branch"` has the option `"--track"` which is 'on' by default. You
-can use `"--no-track"` to override that behaviour. The same goes for `"--color"`
-and `"--no-color"`.
+Options with long option names can be negated by prefixing `--no-`. For
+example, `git branch` has the option `--track` which is 'on' by default. You
+can use `--no-track` to override that behaviour. The same goes for `--color`
+and `--no-color`.

 
 
 Aggregating short options
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 Commands that support the enhanced option parser allow you to aggregate short
 
 
 Aggregating short options
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 Commands that support the enhanced option parser allow you to aggregate short

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

 
 
 Separating argument from the option
 
 
 Separating argument from the option

diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 9afca755ed309b5bdf3cd293d6120f676f1053cd..4fc1cf1184f84b60ee72a9298d23f0464d2edadf 100644 (file)
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -262,7 +262,7 @@ This commit is referred to as a "merge commit", or sometimes just a
        'origin' is used for that purpose. New upstream updates
        will be fetched into remote <<def_tracking_branch,tracking branches>> named
        origin/name-of-upstream-branch, which you can see using
        'origin' is used for that purpose. New upstream updates
        will be fetched into remote <<def_tracking_branch,tracking branches>> named
        origin/name-of-upstream-branch, which you can see using

-       "`git branch -r`".
+       `git branch -r`.

 
 [[def_pack]]pack::
        A set of objects which have been compressed into one file (to save space
 
 [[def_pack]]pack::
        A set of objects which have been compressed into one file (to save space

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 96af8977f6cae5382728f13116ea24ba2d130bef..e33b29b1dd58b373a23a939aa2c587b4430b4ff4 100644 (file)
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1136,10 +1136,10 @@ Ignoring files
 A project will often generate files that you do 'not' want to track with git.
 This typically includes files generated by a build process or temporary
 backup files made by your editor. Of course, 'not' tracking files with git
 A project will often generate files that you do 'not' want to track with git.
 This typically includes files generated by a build process or temporary
 backup files made by your editor. Of course, 'not' tracking files with git

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

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

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

 
 You can tell git to ignore certain files by creating a file called .gitignore
 in the top level of your working directory, with contents such as:
 
 You can tell git to ignore certain files by creating a file called .gitignore
 in the top level of your working directory, with contents such as: