Git log --tags isn't working as expected

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

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

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.

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

Jeff King <peff@peff.net> writes:

Nit: dashed options come first and then revs and then pathspecs.

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

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

Jeff King <peff@peff.net> writes:

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

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

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