Re: [PATCH 2/3] submodule: implement `module_name` as a builtin helper

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Beller <sbeller@xxxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]