Re: [PATCH 2/2] bundle: rewrite builtin to use parse-options

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 9, 2011, 13:33 UTC
Message-ID: <m34nx9j2fc.fsf@localhost.localdomain>
In-Reply-To: <7viplqhbgs.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 21 quoted lines

> Ramkumar Ramachandra <artagnon@gmail.com> writes:
> 
> > That being said, do you see value in lifting the restriction on
> > opts->long_name and PARSE_OPTS_NODASH not allowed together?  The
> > restriction seems quite arbitrary, but I can't justify lifting it
> > unless I can show some valid usecase.
> 
> True and true.
> 
> As to the first "true", it is because the nodash was introduced only to
> parse "find ... \( ... \)" style parentheses as if they are part of option
> sequence, and that use case only needed a single letter.
> 
> As to the second "true", it is because so far we didn't need anything
> longer.
> 
> I do not think the name of a subcommand is not a good use case example for
> it, by the way. Unlike parentheses on the command line of "find" that can
> come anywhere and there can be more than one, the subcommand must be the
> first thing on the command line and only one subcommand is given at one
> command invocation.

Well, I think it doesn't have to be true: there can be some options like e.g. '-n' / '--dry-run' that are common to all subcommands, and in my opinion they could come before subcommand name.

But if restriction that subcommand name must be first simplifies code, then let's do it this way.

I agree that subcommands are and must be mutually exclusive -- otherwise they better be implemented as options, not subcommands.

-- 
Jakub Narębski