Re: [PATCH v3] rev-parse --parseopt: option argument name hints

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 21, 2014, 17:04 UTC
Message-ID: <xmqqvbv7v5xh.fsf@gitster.dls.corp.google.com>
In-Reply-To: <532B7774.30308@gmail.com>

Ilya Bobyr <ilya.bobyr@gmail.com> writes:

Show 15 quoted lines

>>> +	`<arg_hing>`, if specified, is used as a name of the argument in the
>>> +	help output, for options that take arguments. `<arg_hint>` is
>>> +	terminated by the first whitespace. When output the name is shown in
>>> +	angle braces.  Underscore symbols are replaced with spaces.
>> The last part is troubling (and sounds not very sane).  Do we do
>> such a munging anywhere else, or is it just here?  If the latter I'd
>> prefer not to see such a hack.
>
> The following commands have spaces in argument names in the "-h"
> output for one or two arguments:
>   * clone
>   * commit
>   * merge
>
> A number of commands use dashes to separate words in arguments names.

That was not what I asked. I was asking if there is a precedent to use "you cannot have underscores in hint; they will be turned into spaces" quoting convention. I do not think of any (we either do a backslash-quote, c-quote inside dq-pair, or %20, depending on the context).

Personally, because these "hints" are not even hints (they are more like placeholders for value that makes it easier to refer to in the description of an option [*1*]), I wouldn't shed tears if scripted Porcelains cannot use a space in the argh. In fact, it probably makes the result harder to read and format more funnily if you had a space in the argh string, be it in a subcommand implemented in C or in a scripted Porcelain.

"An optional argh is terminated by a whitespace" is perfectly fine, and by doing so we do not have to worry about having to introduce a new quoting convention like you did, which is a big plus.

[Footnote]

*1* Perhaps like this:

	--gpg-sign[=<key-id>]
        	Sign (with the key specified with <key-id>)