Re: [puzzled and solved] "shortlog" not quite understanding all "log" options

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [puzzled and solved] "shortlog" not quite understanding all "log" options

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:01:26

Jeff King [off-list ref] writes:
On Fri, May 30, 2014 at 12:28:47PM -0700, Junio C Hamano wrote:
quoted
.... Aaaand, it turns out that the answer is in the big comment at
the beginning of handle_revision_pseudo_opt().

-- >8 --
Subject: shortlog: allow --exclude=<glob> to be passed

e7b432c5 (revision: introduce --exclude=<glob> to tame wildcards,
2013-08-30) taught a new option to the command-line parser of "log"
and friends, but did not wire it fully so that it can also be used
by "shortlog".
FWIW, I think the discussion above the scissors adds a lot to the
context. It might be nice to add it to the commit message.
OK.  Try to remember when I reroll it.
I am slightly puzzled why parse_revision_opt does not just call
handle_revision_pseudo_opt. According to f6aca0dc4, it is because
pseudo-options need to be acted on in-order, as they affect things like
subsequent "--not" options, etc. But if we are using parse_options_step,
shouldn't we be handling the options in order?

I am sure I am just missing something obvious, so do not trouble
yourself if you do not know the answer offhand.
Sorry, I don't know ;-)

Re: [puzzled and solved] "shortlog" not quite understanding all "log" options

From: Jeff King <hidden>
Date: 2016-06-15 23:01:40

On Fri, May 30, 2014 at 02:37:02PM -0700, Junio C Hamano wrote:
quoted
I am slightly puzzled why parse_revision_opt does not just call
handle_revision_pseudo_opt. According to f6aca0dc4, it is because
pseudo-options need to be acted on in-order, as they affect things like
subsequent "--not" options, etc. But if we are using parse_options_step,
shouldn't we be handling the options in order?

I am sure I am just missing something obvious, so do not trouble
yourself if you do not know the answer offhand.
Sorry, I don't know ;-)
Hopefully I am not wasting your time by responding to an old thread, but
I figured this out and wanted to post it for posterity.

The answer is that it is not about handling _options_ in order, but that
we need to handle pseudo-options in order with non-options, like:

  foo --not bar

Stepping through the options with parseopt will just cover dashed
options, but we handle non-option arguments later. So we have to handle
the pseudo-arguments like "--not" at the same later time.

So there's nothing interesting to clean up or fix here.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help