From: Junio C Hamano <gitster@pobox•com>
To: Stefan Beller <sbeller@google•com>
Cc: peff@peff•net, git@vger•kernel.org, jrnieder@gmail•com,
johannes.schindelin@gmail•com, Jens.Lehmann@web•de
Subject: Re: [PATCH 2/3] submodule: implement `module_name` as a builtin helper
Date: Mon, 31 Aug 2015 13:35:09 -0700 [thread overview]
Message-ID: <xmqqwpwbtcw2.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1441048767-29729-3-git-send-email-sbeller@google.com> (Stefan Beller's message of "Mon, 31 Aug 2015 12:19:26 -0700")
Stefan Beller <sbeller@google•com> writes:
> usage:
> - usage("git submodule--helper module_list\n");
> + usage("git submodule--helper [module_list | module_name]\n");
To me, the above reads as if saying:
The command takes one of the two subcommands at this stage,
module_list that does not take any parameter, and module_name
that does not take any parameter.
which is not what you intended.
I think that the help for individual options and arguments are
sufficiently given in the implementation of each subcommand
(e.g. module_list does its own parse_options() thing), so there is
no need to duplicate them here. The only purpose of this usage serves
is to tell the user that the subcommand name was not understood, and
give the list of available subcommands. For that, I wonder if the
usual single-liner "usage" is the best way to do so.
$ git submodule--helper frotz
fatal: 'frotz' is not a valid submodule--helper subcommand, which are
module_list, module_name.
or something along that line, perhaps, may be more appropriate?
next prev parent reply other threads:[~2015-08-31 20:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-31 19:19 [PATCHv2 0/3] submodule--helper: Have some refactoring only patches first Stefan Beller
2015-08-31 19:19 ` [PATCH 1/3] submodule: implement `module_list` as a builtin helper Stefan Beller
2015-08-31 21:55 ` Eric Sunshine
2015-08-31 19:19 ` [PATCH 2/3] submodule: implement `module_name` " Stefan Beller
2015-08-31 20:35 ` Junio C Hamano [this message]
2015-08-31 20:51 ` Stefan Beller
2015-08-31 22:01 ` Eric Sunshine
2015-08-31 19:19 ` [PATCH 3/3] submodule: implement `module_clone` " Stefan Beller
2015-08-31 22:35 ` Eric Sunshine
2015-09-01 17:49 ` Stefan Beller
2015-09-01 18:35 ` Eric Sunshine
2015-08-31 20:15 ` [PATCHv2 0/3] submodule--helper: Have some refactoring only patches first Junio C Hamano
2015-09-01 0:40 ` [PATCHv3 " Stefan Beller
2015-09-01 0:40 ` [PATCHv3 1/3] submodule: implement `module-list` as a builtin helper Stefan Beller
2015-09-01 2:22 ` Eric Sunshine
2015-09-01 0:40 ` [PATCHv3 2/3] submodule: implement `module-name` " Stefan Beller
2015-09-01 2:31 ` Eric Sunshine
2015-09-01 16:18 ` Stefan Beller
2015-09-01 0:40 ` [PATCHv3 3/3] submodule: implement `module-clone` " Stefan Beller
2015-09-01 2:41 ` Eric Sunshine
2015-09-01 2:09 ` [PATCHv3 0/3] submodule--helper: Have some refactoring only patches first Eric Sunshine
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=xmqqwpwbtcw2.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=Jens.Lehmann@web$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=johannes.schindelin@gmail$(echo .)com \
--cc=jrnieder@gmail$(echo .)com \
--cc=peff@peff$(echo .)net \
--cc=sbeller@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox