Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
- From
Pierre Habouzit <madcoder@debian.org>
- Date
- Dec 17, 2007, 12:33 UTC
- Message-ID
- <20071217123307.GK7453@artemis.madism.org>
- In-Reply-To
- <7v1w9la7o8.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 17, 2007 at 11:21:11AM +0000, Junio C Hamano wrote:
Show 23 quoted lines
> Pierre Habouzit <madcoder@debian.org> 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@debian.org OOO http://www.madism.org