From: Tim Henigan <tim.henigan@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH RFC] git remote: Separate usage strings for subcommands
Date: Mon, 16 Nov 2009 20:39:09 -0500 [thread overview]
Message-ID: <32c343770911161739g203a32d4p2b9f8ea6b39d900@mail.gmail.com> (raw)
In-Reply-To: <7vocn2klp8.fsf@alter.siamese.dyndns.org>
On Mon, Nov 16, 2009 at 8:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Tim Henigan <tim.henigan@gmail.com> writes:
>
>> ...
>> +static const char * const builtin_remote_add_usage[] = {
>> REMOTE_ADD_USAGE, NULL };
>> ...
>
> I am not sure about the value of reusing option string like this, and for
> all other subcommands the same comment applies. For example, in the case
> of "remote add -h", you would use
>
> "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
> from REMOTE_ADD_USAGE, but ...
Do you object to the new #defines for the strings? I added them since we now
really need to construct the usage string for 2 separate uses:
(1) When 'git remote -h' is invoked, we need to return the usage
string showing
all subcommands.
(2) When 'git remote <subcommand> -h' is invoked, we need to return the
usage for just that command.
It doesn't make sense to me to maintain separate strings for the two use cases.
>> @@ -70,7 +87,6 @@ static int add(int argc, const char **argv)
>> int i;
>>
>> struct option options[] = {
>> - OPT_GROUP("add specific options"),
>> OPT_BOOLEAN('f', "fetch", &fetch, "fetch the remote branches"),
>> OPT_CALLBACK('t', "track", &track, "branch",
>> "branch(es) to track", opt_parse_track),
>> @@ -79,11 +95,11 @@ static int add(int argc, const char **argv)
>> OPT_END()
>> };
>>
>> - argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
>> + argc = parse_options(argc, argv, NULL, options, builtin_remote_add_usage,
>> 0);
>
> ... the options list is used to reproduce the information in a major part
> of that string already. So I would prefer builtin_remote_add_usage[] to
> be something like:
>
> "git remote add [<options>...] <name> <url>"
>
> It is in line with a discussion we had earlier:
>
> http://thread.gmane.org/gmane.comp.version-control.git/129906/focus=130646
I planned to make this change in a separate (or maybe just a later
version) patch,
but first I wanted to be sure my other changes were sound. I will send a new
version that includes this change.
Should this change be made to the man page as well?
>> @@ -1334,7 +1348,6 @@ static int show_all(void)
>> int cmd_remote(int argc, const char **argv, const char *prefix)
>> {
>> struct option options[] = {
>> - OPT__VERBOSE(&verbose),
>> OPT_END()
>> };
>> int result;
I did find one problem with the above portion of the patch. With this change
'-v' was no longer recognized as an option. I will remove this change in the
next version. Keeping it means that '-v' will still be reported in the
'git remote -h' usage string, but I don't see an easy way to remove the string
without removing the feature.
prev parent reply other threads:[~2009-11-17 1:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-15 21:43 [PATCH RFC] git remote: Separate usage strings for subcommands Tim Henigan
2009-11-17 1:02 ` Junio C Hamano
2009-11-17 1:39 ` Tim Henigan [this message]
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=32c343770911161739g203a32d4p2b9f8ea6b39d900@mail.gmail.com \
--to=tim.henigan@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).