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

From: Pierre Habouzit <madcoder@debian.org>
Date: Dec 17, 2007, 20:42 UTC
Message-ID: <20071217204204.GA13004@artemis.madism.org>
In-Reply-To: <20071217203143.GA2105@coredump.intra.peff.net>

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

Show 16 quoted lines

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

  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.

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

  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