Re: Git log --tags isn't working as expected

From: Jeff King <peff@peff.net>
Date: Aug 2, 2017, 17:34 UTC
Message-ID: <20170802173411.tu7wyuehcktxge6o@sigill.intra.peff.net>
In-Reply-To: <xmqqa83idjlj.fsf@gitster.mtv.corp.google.com>

On Wed, Aug 02, 2017 at 09:23:36AM -0700, Junio C Hamano wrote:

Show 8 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> >   3. Use --simplify-by-decoration to show a particular range of commits,
> >      but limit to ones that actually have a ref pointing at them. Like:
> >
> >        git log <COMMIT_ID>..HEAD --simplify-by-decoration
> 
> Nit: dashed options come first and then revs and then pathspecs.

Well, sort of. It does work just fine, and always has. I always thought we were following the GNU-style liberal option ordering.

By the way, I noticed something funny that I forgot to mention:

  git log --tags=does-not-exist

shows HEAD, because the logic to kick in the default only asks "were we given any refs to start the traversal?". I think it probably should consider a wildcard with no matches to override the default, and show nothing.

I haven't decided if it should be empty-but-success, or give an error. And if an error, if it is "you tried to give me refs, but they showed nothing" or "you gave me a wildcard that matched nothing". The distinction matters for:

  git log --tags=does-not-exist --tags=does-exist

which currently allows the empty wildcard to be a noop.

-Peff