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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 17, 2007, 10:53 UTC
Message-ID: <7vir2xa8z7.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20071217090749.GC7453@artemis.madism.org>

Pierre Habouzit <madcoder@debian.org> writes:

Show 6 quoted lines

>   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.