Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
- From
Pierre Habouzit <madcoder@debian.org>
- Date
- Dec 17, 2007, 09:07 UTC
- Message-ID
- <20071217090749.GC7453@artemis.madism.org>
- In-Reply-To
- <7vd4t5eq52.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 17, 2007 at 07:28:41AM +0000, Junio C Hamano wrote:
Show 7 quoted lines
> The command freely used optional option-argments for its -l and -n options. > I think allowing "git tag -n xxx" without barfing was an error to begin with, > but not supporting "git tag -l pattern" form is a serious regression. > > So this fixes the handling of -l to reinstate the original behaviour while > detecting a user error "git tag -l pattern garbage", and adjusts tests that > use "-n param" form to use "-nparam".
Show 14 quoted lines
> - if (list)
> + if (list) {
> + /*
> + * This is unfortunate but requiring "git tag -lpattern" and not
> + * allowing "git tag -l pattern" is a serious regression.
> + */
> + if (argc && list == no_pattern) {
> + list = argv[0];
> + argc--;
> + }
> + if (argc)
> + die("extra argument after -l[pattern]: %s", argv[0]);
> return list_tags(list == no_pattern ? NULL : list, 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, and I find it nowhere near acceptable. I believe the fix is worse than the disease. 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.
-- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org