From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 17 Dec 2007 10:53:00 GMT
Subject: Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
Message-ID: <7vir2xa8z7.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20071217090749.GC7453@artemis.madism.org>

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.