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

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

Pierre Habouzit [off-list ref] writes:

quoted

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