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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> Jeff King <peff@xxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux