From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 19 Nov 2009 18:10:44 GMT
Subject: Re: [PATCH v4] git remote: Separate usage strings for subcommands
Message-ID: <7vlji2bd23.fsf@alter.siamese.dyndns.org>
In-Reply-To: <32c343770911190651w3f1ac9b6i2d3b1a62a032489f@mail.gmail.com>

Tim Henigan <tim.henigan@gmail.com> writes:

> The original version of this patch [1] left the contents of the usage
> strings intact.  However, Junio expressed a preference to change
> them to use the generic <options>.  See this thread for the
> discussion [2].
>
> [1] http://article.gmane.org/gmane.comp.version-control.git/133048/
> [2] http://thread.gmane.org/gmane.comp.version-control.git/132968/focus=133050

Sorry, but I think you misunderstood what I meant, then.  in [2], I said...

    > ... hunk to remove literal strings from builtin_remote_usage[] 
    > ... and replace them with REMOTE_BARE_USAGE, REMOTE_ADD_USAGE

    I am not sure about the value of reusing option string like this, and for

Here, please note that I was objecting to the use of _the same string_ in
both contexts ("reusing").

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

    > ... hunk to give the builtin_remote_add_usage[] that  uses the same
    > ... REMOTE_ADD_USAGE to parse_options() 

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

I meant that we want to change "remote add -h" to show this here; and the
reason why I doubted "the value of reusing option string" was because I
wanted to do so without touching the concise list of the subcommands and
their options given by "remote -h".  Otherwise, it would have made perfect
sense to use preprocessor macros to share the two identical strings.

In your response to my above comment, you indicated that you wanted to do
the [<options>] thing as a separate patch (your original patch spelled
options in full).  I took it to mean that you would do that only for the
subcommand help, and did not respond, because

 (1) doing that to the subcommand help would be a good idea anyway; and

 (2) you will realize what I said in the message about "the value of
     reusing option string" was correct when you see the end result, which
     will regress "remote -h" output.

In this case, unfortunately (2) didn't happen before Nana pointed it out.