Re: [PATCH] push: comment on a funny unbalanced option help

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 2, 2018, 15:31 UTC
Message-ID: <xmqqftzw4weq.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <30a6105c-4cb7-b52f-0b0a-c4504b90a5b1@web.de>

René Scharfe <l.s.r@web.de> writes:

> We could check if argh comes with its own angle brackets already and
> not add a second pair in that case, making PARSE_OPT_LITERAL_ARGHELP
> redundant in most cases, including the one above.  Any downsides?
> Too magical?

Hmph.

Show 10 quoted lines

> -- >8 --
> Subject: [PATCH] parse-options: automatically infer PARSE_OPT_LITERAL_ARGHELP
>
> Avoid adding an extra pair of angular brackets if the argh string
> already contains one.  Remove the flag PARSE_OPT_LITERAL_ARGHELP in the
> cases where the new automatic handling suffices.  This shortens and
> simplifies option definitions with special argument help strings a bit.
>
> Signed-off-by: Rene Scharfe <l.s.r@web.de>
> ---

>  		{ OPTION_STRING, 0, "prefix", &opts.prefix, N_("<subdirectory>/"),
>  		{ OPTION_CALLBACK, 'g', "reflog", &reflog_base, N_("<n>[,<base>]"),
>  			N_("<mode>,<object>,<path>"),
> +		OPT_STRING(0, "prefix", &prefix, N_("<prefix>/"),

Hmph.

Show 11 quoted lines

> diff --git a/parse-options.c b/parse-options.c
> index 7db84227ab..fadfc6a833 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -660,7 +660,8 @@ int parse_options(int argc, const char **argv, const char *prefix,
>  static int usage_argh(const struct option *opts, FILE *outfile)
>  {
>  	const char *s;
> -	int literal = (opts->flags & PARSE_OPT_LITERAL_ARGHELP) || !opts->argh;
> +	int literal = (opts->flags & PARSE_OPT_LITERAL_ARGHELP) || !opts->argh ||
> +		(opts->argh[0] == '<' && strchr(opts->argh, '>'));

You are greedier than what I thought ;-) I would have limited this magic to the case where argh is surrounded by "<>", but you allow one closing ">" anywhere, which allows us to grab more complex cases.

The lack of escape hatch to decline this auto-literal magic makes me somewhat nervous, but I do not offhand think of a reason why I do want an arg-help string that _begins_ with '<' to be enclosed by another set of "<>", so perhaps this is a good kind of magic.