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

On Mon, Dec 17, 2007 at 08:31:43PM +0000, Jeff King wrote:

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

quoted

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

I agree with everything you said, except...

quoted

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

  Yes, that's why the restriction bugs me a bit too.

  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.

  there are some, I don't recall the exact commands, but option parsing
was quite inconsistent in git (well still is), there are the very simple
loops that just do strcmp and look for the '=', there are the loops that
allow interleaving of options and arguments (and that rewrite argc/argv
a bit like parseopt does) and also the ones that allow the separate
mode, and the one that do both.

  The force-stick-mode is a regression for them.

quoted

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

  Yes for git tag -n for example, and there are some other
examples, look at maint for commands that have been migrated to
parse_options, some behave like that, and more than one for sure.

  3. It's longer to type.

  It's way more readable, but YMMV.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org