git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

      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).