Git log --tags isn't working as expected

Git log --tags isn't working as expected

[Richard Jones]

Hi,

I’m trying to locate a commit which takes place after another one,
matches a certain tag, and is by a specific user. I have the following
command:

git log <COMMIT_ID>..HEAD --decorate --author=“<AUTHOR>" --tags=“project-name”

The tag follows the format: project-name-version

How ever this doesn’t seem to work, as it returns all the commits by
that user since the commit ID supplied.

There is also another tag, the release version which follows the
format: x.y.z. I have tried searching for this, using:

git log --tags=“x.y.z”

But it returns all the commits, not just a specific one. The tag I am
searching for is returned by: git tag

My understanding from the docs
(https://git-scm.com/docs/git-log#git-log---tagsltpatterngt) is that
git log should only return matches to the —tags argument pattern.

I have tried using git version 2.11.0 (Apple Git-81) and version 2.13.3.

Cheers,
Rich

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

[Jeff King]

On Wed, Aug 02, 2017 at 08:41:41AM +0100, Richard Jones wrote:

> I’m trying to locate a commit which takes place after another one,
> matches a certain tag, and is by a specific user. I have the following
> command:
> 
> git log <COMMIT_ID>..HEAD --decorate --author=“<AUTHOR>" --tags=“project-name”
> 
> The tag follows the format: project-name-version

I think you want --tags="project-name-*", as the pattern is a glob. If
you omit any wildcards, it does a prefix match, but only at "/"
boundaries. That's the implied "/*" from the docs:

  --tags[=<pattern>]
    Pretend as if all the refs in refs/tags are listed on the command
    line as <commit>. If <pattern> is given, limit tags to ones matching
    given shell glob. If pattern lacks ?, *, or [, /* at the end is implied.

> How ever this doesn’t seem to work, as it returns all the commits by
> that user since the commit ID supplied.

Your ref selector "--tags" didn't match anything. So we just showed
<COMMIT_ID>..HEAD.

However, I suspect "--tags" still doesn't quite do what you want. It
behaves as if each tag was given as a starting point for a traversal. So
we'd generally show <COMMIT_ID>..HEAD in _addition_ to any tags we found
(and any commits reachable from those tags, down to <COMMIT_ID>). But it
sounds like you want to just see tags. For that, I'd do one of:

  1. Ask git-tag to show the interesting bits of your tags, like:

       git tag --format='%(refname:short) %(*authorname) / %(*subject)'

     The "*" there is dereferencing the tag to show the underlying
     commit. See the FIELD NAMES section of git-for-each-ref for more
     details. You can further limit that to tags that contain a
     particular commit with "--contains <COMMIT_ID>".

  2. Feed git-log some ref tips but ask it not to walk:

       git log --no-walk --tags='project-name-*'

     This is similar to (1), but uses the revision machinery, which can
     show more about each commit (e.g., the diff). But I don't think
     there's a good way to ask only for the tips that contain your
     particular commit (a negative endpoint like "<COMMIT_ID>.." doesn't
     play well with --no-walk, I think).

  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

I think (3) matches what you're trying to do the best. You can't say
"just tags" for the decoration, though, so you'll see branch tips as
well. There's been some discussion about allowing specific decorations,
but nothing merged yet.

-Peff

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

[Junio C Hamano]

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.

> I think (3) matches what you're trying to do the best. You can't say
> "just tags" for the decoration, though, so you'll see branch tips as
> well. There's been some discussion about allowing specific decorations,
> but nothing merged yet.

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

[Jeff King]

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

> 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

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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.

I agree.  The same for --branches, --glob, etc.  I'd say it should
behave just like "git log HEAD..HEAD".

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

[Jeff King]

On Wed, Aug 02, 2017 at 01:28:38PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > 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.
> 
> I agree.  The same for --branches, --glob, etc.  I'd say it should
> behave just like "git log HEAD..HEAD".

Thanks for confirming. That's the way I lean, too. And I found some
related tests for rev-list in t6018 that expect that, too (but are
currently marked to fail).

I'll send some patches in a minute, but I'll start a new thread, as
we've drifted off-topic for this one.

-Peff