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

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

   - 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