Thread (3 messages) flat view 3 messages, 2 authors, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:59

Possibly related (same subject, not in this thread)

Pierre Habouzit [off-list ref] 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). 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help