Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.

From: Jeff King <peff@peff.net>
Date: Dec 17, 2007, 20:31 UTC
Message-ID: <20071217203143.GA2105@coredump.intra.peff.net>
In-Reply-To: <7vy7bt6qv6.fsf@gitster.siamese.dyndns.org>

On Mon, Dec 17, 2007 at 11:52:29AM -0800, Junio C Hamano wrote:

> So in short, for an option that takes optional option-argument:

I agree with everything you said, except...

>    - if it is given as "--long-name", and there is a next word, see if
>      that is plausible as its argument.  Get it and signal the caller
>      you consumed it, if it is.  Ignore it and signal the caller you
>      didn't, if it isn't.

This "plausible" makes me a little nervous, and I wonder why we want to support this at all. Is it

  1. We have traditionally supported "--abbrev 10"? I don't think this
     is the case.
  2. Consistency with "--non-optional-arg foo"? Do we have any such
     non-optional long arguments? I didn't see any; I think we stick
     with --non-optional-arg=foo everywhere.
  3. More convenience to the user? I don't see how " " is easier than
     "=".

Show 5 quoted lines

>    - if it is given as "-s", and there is a next word, and if the option
>      has long format counterpart as well, then see if the next word is
>      plausible as its argument.  Get it and signal the caller you
>      consumed it, if it is.  Ignore it and signal the caller you didn't,
>      if it isn't.

Similarly, what is the goal here?

  1. Have we ever supported "-s foo"? Not for -B/-M/-C, nor for
     shortlog's -w.
  2. This would add consistency to non-optional arguments.
  3. It's longer to type.

So I see a slight case for "-s foo", but none at all for "--long foo".

-Peff