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

From: Pierre Habouzit <madcoder@debian.org>
Date: Dec 17, 2007, 21:11 UTC
Message-ID: <20071217211106.GC13004@artemis.madism.org>
In-Reply-To: <7vy7bt6qv6.fsf@gitster.siamese.dyndns.org>

On Mon, Dec 17, 2007 at 07:52:29PM +0000, Junio C Hamano wrote:

Show 22 quoted lines

> Pierre Habouzit <madcoder@debian.org> writes:
> 
> > After having written this mail 4 time already, I came up with an idea I
> > kind of like: like find, we could make {} be a placeholder for the
> > "default" argument. For example:
> >
> >   $ git foo --abbrev {} 10
> >   $ git log -M {} 1
> >   ...
> >
> > {} would have the same semantics as your --long-opt-default. It tells the
> > option parser that "no there isn't anything to grok for that command thank you
> > very much". Of course if for some reason you really want to pass "{}" to the
> > command, the stuck form holds:
> >
> >   $ git foo --long-opt={}
> >   $ git foo -o{}
> >
> > What do you think ?
> 
> 1. {} means a completely different thing to find ("place the real value
>    here"); there is no similarity.  I would strongly oppose to it.  If

  okay we could make it be '_', but …

>    you want to invoke opt with default but still want to pass "{}" as an
>    argument unrelated to that opt, you would do "--opt={} {}".  That's
>    double ugly.

Actually that would be --opt {} {} (or --opt _ _) and indeed it's not very nice (euphemism for it sucks hard).

I like the *-default idea a lot, but it's not really useful if we cannot fix the single letter switches at the same time. I had the idea to use ! (or any other less shell-magical char) like this: --abbrev! but it doesn't fly a lot better for single letter switches.

Well maybe it's not worth fighting any longer, we should stick to the stuck form then :)

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