Skip to content

Commit

Permalink
Merge branch 'jj/doc-markup-hints-in-coding-guidelines'
Browse files Browse the repository at this point in the history
* jj/doc-markup-hints-in-coding-guidelines:
  State correct usage of literal examples in man pages in the coding standards
  • Loading branch information
Junio C Hamano committed Dec 3, 2013
2 parents a2cb44c + ca03c36 commit f0c9253
Showing 1 changed file with 31 additions and 3 deletions.
34 changes: 31 additions & 3 deletions Documentation/CodingGuidelines
Original file line number Diff line number Diff line change
Expand Up @@ -260,9 +260,11 @@ Writing Documentation:

Every user-visible change should be reflected in the documentation.
The same general rule as for code applies -- imitate the existing
conventions. A few commented examples follow to provide reference
when writing or modifying command usage strings and synopsis sections
in the manual pages:
conventions.

A few commented examples follow to provide reference when writing or
modifying command usage strings and synopsis sections in the manual
pages:

Placeholders are spelled in lowercase and enclosed in angle brackets:
<file>
Expand Down Expand Up @@ -312,3 +314,29 @@ Writing Documentation:
Use 'git' (all lowercase) when talking about commands i.e. something
the user would type into a shell and use 'Git' (uppercase first letter)
when talking about the version control system and its properties.

A few commented examples follow to provide reference when writing or
modifying paragraphs or option/command explanations that contain options
or commands:

Literal examples (e.g. use of command-line options, command names, and
configuration variables) are typeset in monospace, and if you can use
`backticks around word phrases`, do so.
`--pretty=oneline`
`git rev-list`
`remote.pushdefault`

Word phrases enclosed in `backtick characters` are rendered literally
and will not be further expanded. The use of `backticks` to achieve the
previous rule means that literal examples should not use AsciiDoc
escapes.
Correct:
`--pretty=oneline`
Incorrect:
`\--pretty=oneline`

If some place in the documentation needs to typeset a command usage
example with inline substitutions, it is fine to use +monospaced and
inline substituted text+ instead of `monospaced literal text`, and with
the former, the part that should not get substituted must be
quoted/escaped.

0 comments on commit f0c9253

Please sign in to comment.