@@ -260,9 +260,11 @@ Writing Documentation:
260260
261261 Every user-visible change should be reflected in the documentation.
262262 The same general rule as for code applies -- imitate the existing
263- conventions. A few commented examples follow to provide reference
264- when writing or modifying command usage strings and synopsis sections
265- in the manual pages:
263+ conventions.
264+
265+ A few commented examples follow to provide reference when writing or
266+ modifying command usage strings and synopsis sections in the manual
267+ pages:
266268
267269 Placeholders are spelled in lowercase and enclosed in angle brackets:
268270 <file>
@@ -312,3 +314,29 @@ Writing Documentation:
312314 Use 'git' (all lowercase) when talking about commands i.e. something
313315 the user would type into a shell and use 'Git' (uppercase first letter)
314316 when talking about the version control system and its properties.
317+
318+ A few commented examples follow to provide reference when writing or
319+ modifying paragraphs or option/command explanations that contain options
320+ or commands:
321+
322+ Literal examples (e.g. use of command-line options, command names, and
323+ configuration variables) are typeset in monospace, and if you can use
324+ `backticks around word phrases`, do so.
325+ `--pretty=oneline`
326+ `git rev-list`
327+ `remote.pushdefault`
328+
329+ Word phrases enclosed in `backtick characters` are rendered literally
330+ and will not be further expanded. The use of `backticks` to achieve the
331+ previous rule means that literal examples should not use AsciiDoc
332+ escapes.
333+ Correct:
334+ `--pretty=oneline`
335+ Incorrect:
336+ `\--pretty=oneline`
337+
338+ If some place in the documentation needs to typeset a command usage
339+ example with inline substitutions, it is fine to use +monospaced and
340+ inline substituted text+ instead of `monospaced literal text`, and with
341+ the former, the part that should not get substituted must be
342+ quoted/escaped.
0 commit comments