verifying syntax for optional and replaceable content in man pages

  willing to submit some patches to standardize the syntax of man
pages in terms of rendering "optional" and/or "replaceable" content,
and it seems like "man git-config" would be a good place to start:

SYNOPSIS
       git config [<file-option>] [type] [--show-origin] [-z|--null] name [value [value_regex]]
       git config [<file-option>] [type] --add name value
       git config [<file-option>] [type] --replace-all name value [value_regex]
       ...snip ...

  can i assume the proper (uniform) syntax for the above would be
(shortening lines):

  ... [<type>] [--show-origin] [-z|--null] <name> [<value> [<value_regex>]]
  ... [<type>] --add <name> <value>
  ... [<type>] --replace-all <name> <value> [<value_regex>]

and so on. is that the consensus? i wouldn't try to do it all at once, maybe just a page at a time to not be too disruptive.

rday

On Wed, May 30, 2018 at 4:39 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:

So the difference are the angle brackets around 'name', otherwise no change?

all the same but angle brackets around name and value,

same.

I would think there is consensus for unifying the syntax across all man pages and put variable texts (name, path, key, value, etc) into angle brackets.

I used git-blame to find all the changes throughout history touching the first line of the synopsis (or rather: I used gitk, right click "show origin of line"), and there were no edit wars whether to use angle brackets or not; it looks like nobody cared or paid attention since the first revision of that line, which is

    git-config' [--global] [type] name [value [value_regex]]

from e0d10e1c63b ([PATCH] Rename git-repo-config to git-config., 2007-01-28)

Thanks for taking care of these! Stefan

On Wed, 30 May 2018, Stefan Beller wrote:

  more precisely, angle brackets would represent any "replaceable"
content, regardless of where it occurs.

  same rationale as above, [<...>] would represent both optional *and*
replaceable content. and so on, and so on.

  the only other obvious inconsistency i've seen is, when referring to
an environment variable, i've seen both of:

  `VARIABLE`
  `$VARIABLE`

my personal preference is the one without the $ if just referring to the variable, without trying to dereference it. but that's just me.

rday