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

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

Pierre Habouzit <madcoder@debian.org> writes:

Show 7 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). This hack allows:
>
>   git tag -l -n10 <pattern>
>
> and will then attach the <pattern> to the '-l' switch,...

Heh, it turns out that we were both stupid and blind.

Look at contrib/examples/git-tag.sh again.

The original addition of "-n <count>" was suboptimal and did not allow "git tag -l -n10 <glob>", but I would actually call that a bug of the -n <count> implementation (it wanted to affect working of other option, so at that point it should have restructured the loop and made parsing of options and carrying out of actions separate steps).

The -l option tells "git tag" to work in "list tags" mode, and in that mode, the command itself takes zero or one (we could have taken more but we didn't) glob to limit the listing. The <glob> is not even an option argument to option -l, but the arguments to "git tag" command itself.

So "git-tag -l" was a bad example of an option that takes optional option-argument, and you can see that the conversion to parse_options() done in 396865859918e9c7bf8ce74aae137c57da134610 (Make builtin-tag.c use parse_options.) broke it.

IOW, the fixup I posted was not a workaround but happens to be a bugfix to the above commit that did parse_options() conversion.