All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Carlo Marcelo Arenas Belón" <carenas@gmail.com>
Cc: git@vger.kernel.org, bagasdotme@gmail.com, emilyshaffer@google.com
Subject: Re: [PATCH 1/2] bugreport: avoid duplicating options in usage()
Date: Tue, 07 Sep 2021 14:39:43 -0700	[thread overview]
Message-ID: <xmqq35qg9iao.fsf@gitster.g> (raw)
In-Reply-To: <20210904021231.88534-2-carenas@gmail.com> ("Carlo Marcelo Arenas Belón"'s message of "Fri, 3 Sep 2021 19:12:30 -0700")

Carlo Marcelo Arenas Belón  <carenas@gmail.com> writes:

> 238b439d69 (bugreport: add tool to generate debugging info, 2020-04-16)
> includes the options with the commandline, which then means they will
> be duplicated in the output of `git bugreport -h`.
>
> remove them and while at it, make sure usage() is called if the wrong
> number of parameters is provided (ex: `git bugreport help`)

'remove' -> 'Remove'.

>  static const char * const bugreport_usage[] = {
> -	N_("git bugreport [-o|--output-directory <file>] [-s|--suffix <format>]"),
> +	N_("git bugreport"),

I do not quite see this as an improvement.  Without this change, the
user will see

	usage: git bugreport [-o <file>] [-s <format>]

	    -o <file>
		... explanation of what -o does ...
	    -s <format>
		... explanation of what -s does ...

and with the patch, it becomes unclear, especially for those who are
not used to "git subcommand -h" output convention, as we'd see only

	usage: git bugreport

on the first line, no?  If the patch is to use

	N_("git bugreport [<options>]")

as the new text, then that would be an improvement, though.

> @@ -141,6 +140,8 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
>  
>  	argc = parse_options(argc, argv, prefix, bugreport_options,
>  			     bugreport_usage, 0);
> +	if (argc)
> +		usage_with_options(bugreport_usage, bugreport_options);

This is a good change (until we gain positional argument to the
subcommand, at which time we'd need to rethink the error checking).

>  	/* Prepare the path to put the result */
>  	prefixed_filename = prefix_filename(prefix,

  reply	other threads:[~2021-09-07 21:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03 11:59 [PATCH] Documentation: fix default directory of git bugreport -o Bagas Sanjaya
2021-09-04  2:12 ` bugreport papercuts Carlo Marcelo Arenas Belón
2021-09-04  2:12   ` [PATCH 1/2] bugreport: avoid duplicating options in usage() Carlo Marcelo Arenas Belón
2021-09-07 21:39     ` Junio C Hamano [this message]
2021-09-04  2:12   ` [PATCH 2/2] bugreport: slightly better memory management Carlo Marcelo Arenas Belón
2021-09-07 21:56     ` Junio C Hamano
2021-09-04  6:01   ` bugreport papercuts Bagas Sanjaya
2021-09-07 21:09 ` [PATCH] Documentation: fix default directory of git bugreport -o Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq35qg9iao.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=bagasdotme@gmail.com \
    --cc=carenas@gmail.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.