From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 08 Dec 2011 23:48:03 GMT
Subject: Re: [PATCH 2/2] bundle: rewrite builtin to use parse-options
Message-ID: <7viplqhbgs.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0nCuFgS8PKkQLMzqpBsOWouSs5y=CEKS1r0x0=LkhqC9A@mail.gmail.com>

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.