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

> Pierre Habouzit <madcoder@debian.org> writes:
> 
> >   Okay this is kind of disgusting, and I'm absolutely not pleased with
> > it (I mean I'm not pleased that parse_opt forces us to write things like
> > that).
> > ...
> > I'll try to think harder about what we can do about it. Though for now,
> > we will have to go for it for a while.
> 
> This is just a quick idea before I go back to sleep, but your earlier
> comment on "--no-<an-option-that-is-not-even-boolean>" made me realize
> that the alternative I was suggesting earlier would actually work much
> nicer, if you introduce "--<an-option-that-take-optional-arg>-default"
> magic.

> Then, normal users who know what the value of $foo is (iow, not scripts)
> can say:
> 
> 	git cmd --abbrev 10
>         git cmd --abbrev HEAD
>         git cmd --abbrev=10 HEAD
> 
> and scripts that want to have $foo to be treated as rev, even when it
> consists entirely of digits, can say:
> 
> 	git cmd --abbrev-default $foo
> 
> to disambiguate (i.e.  like "--no-" magic, "-default" is a magic, and it
> tells the parser that "there is no option-argument given to this").
> 
> To make sure $foo is treated as the precision, the script can say:
> 
> 	git cmd --abbrev=$foo
> 
> If the script wants DWIM just like human users want, it can do:
> 
> 	git cmd --abbrev $foo
> 
> There of course is a little details called coding, but I think this is
> probably the most user friendly to the users and the scripts alike.  It
> certainly is nicer than what the current parse_options() does, and/or
> the git-tag workaround does.