On Mon, Dec 17, 2007 at 11:21:11AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@xxxxxxxxxx> writes:
>
> > On Mon, Dec 17, 2007 at 10:53:00AM +0000, Junio C Hamano wrote:
> > ...
> >> 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.
> >
> > meeeow I love the idea !
>
> There is a bit more serious issue than coding, actually.
>
> Short options.
>
> A script wants to use default rename detection threshold for unknown
> commit $foo whose name might look like a number. IOW, this
>
> git diff -M $foo
>
> could be ambiguous. Obviously, "git diff -M-default $foo" would not fly
> very well.
Yes, I thought about that too actually.
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 ?
PS: I know that in some shells {} needs escaping, which isn't nice. I chose it
because it's the same as find(1) but we could e.g. use '_' that is less
"conventional" (if it even makes sense) but is a bit easier to type than \{}.
--
·O· Pierre Habouzit
··O madcoder@xxxxxxxxxx
OOO http://www.madism.org
Attachment:
pgpaWSzYG0VcK.pgp
Description: PGP signature
