{"thread":{"id":"46499","subject":"Git log --tags isn't working as expected","startedAt":"2017-08-02T07:41:47Z","lastAt":"2017-08-02T22:15:18Z","messageCount":6,"participants":["Richard Jones","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"325417","messageId":"CACq05g+4HH9L_fiFLR8php=w5JkqB0792SzR9EZU-o+QHuoM8A@mail.gmail.com","threadId":"46499","inReplyTo":null,"subject":"Git log --tags isn't working as expected","fromName":"Richard Jones","fromEmail":"richardj@backbase.com","sentAt":"2017-08-02T07:41:41Z","receivedAt":"2017-08-02T07:41:47Z","isPatch":false,"sender":{"key":"richardj@backbase.com","avatar":null},"body":"Hi,\n\nI’m trying to locate a commit which takes place after another one,\nmatches a certain tag, and is by a specific user. I have the following\ncommand:\n\ngit log ..HEAD --decorate --author=“\" --tags=“project-name”\n\nThe tag follows the format: project-name-version\n\nHow ever this doesn’t seem to work, as it returns all the commits by\nthat user since the commit ID supplied.\n\nThere is also another tag, the release version which follows the\nformat: x.y.z. I have tried searching for this, using:\n\ngit log --tags=“x.y.z”\n\nBut it returns all the commits, not just a specific one. The tag I am\nsearching for is returned by: git tag\n\nMy understanding from the docs\n(https://git-scm.com/docs/git-log#git-log---tagsltpatterngt) is that\ngit log should only return matches to the —tags argument pattern.\n\nI have tried using git version 2.11.0 (Apple Git-81) and version 2.13.3.\n\nCheers,\nRich\n"},{"id":"325418","messageId":"20170802083200.3rmnz6mx2wfoarng@sigill.intra.peff.net","threadId":"46499","inReplyTo":"CACq05g+4HH9L_fiFLR8php=w5JkqB0792SzR9EZU-o+QHuoM8A@mail.gmail.com","subject":"Re: Git log --tags isn't working as expected","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-02T08:32:01Z","receivedAt":"2017-08-02T08:32:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 02, 2017 at 08:41:41AM +0100, Richard Jones wrote:\n\n> I’m trying to locate a commit which takes place after another one,\n> matches a certain tag, and is by a specific user. I have the following\n> command:\n> \n> git log ..HEAD --decorate --author=“\" --tags=“project-name”\n> \n> The tag follows the format: project-name-version\n\nI think you want --tags=\"project-name-*\", as the pattern is a glob. If\nyou omit any wildcards, it does a prefix match, but only at \"/\"\nboundaries. That's the implied \"/*\" from the docs:\n\n --tags[=]\n Pretend as if all the refs in refs/tags are listed on the command\n line as . If is given, limit tags to ones matching\n given shell glob. If pattern lacks ?, *, or [, /* at the end is implied.\n\n> How ever this doesn’t seem to work, as it returns all the commits by\n> that user since the commit ID supplied.\n\nYour ref selector \"--tags\" didn't match anything. So we just showed\n..HEAD.\n\nHowever, I suspect \"--tags\" still doesn't quite do what you want. It\nbehaves as if each tag was given as a starting point for a traversal. So\nwe'd generally show ..HEAD in _addition_ to any tags we found\n(and any commits reachable from those tags, down to ). But it\nsounds like you want to just see tags. For that, I'd do one of:\n\n 1. Ask git-tag to show the interesting bits of your tags, like:\n\n git tag --format='%(refname:short) %(*authorname) / %(*subject)'\n\n The \"*\" there is dereferencing the tag to show the underlying\n commit. See the FIELD NAMES section of git-for-each-ref for more\n details. You can further limit that to tags that contain a\n particular commit with \"--contains \".\n\n 2. Feed git-log some ref tips but ask it not to walk:\n\n git log --no-walk --tags='project-name-*'\n\n This is similar to (1), but uses the revision machinery, which can\n show more about each commit (e.g., the diff). But I don't think\n there's a good way to ask only for the tips that contain your\n particular commit (a negative endpoint like \"..\" doesn't\n play well with --no-walk, I think).\n\n 3. Use --simplify-by-decoration to show a particular range of commits,\n but limit to ones that actually have a ref pointing at them. Like:\n\n git log ..HEAD --simplify-by-decoration\n\nI think (3) matches what you're trying to do the best. You can't say\n\"just tags\" for the decoration, though, so you'll see branch tips as\nwell. There's been some discussion about allowing specific decorations,\nbut nothing merged yet.\n\n-Peff\n"},{"id":"325438","messageId":"xmqqa83idjlj.fsf@gitster.mtv.corp.google.com","threadId":"46499","inReplyTo":"20170802083200.3rmnz6mx2wfoarng@sigill.intra.peff.net","subject":"Re: Git log --tags isn't working as expected","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-02T16:23:36Z","receivedAt":"2017-08-02T16:23:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> 3. Use --simplify-by-decoration to show a particular range of commits,\n> but limit to ones that actually have a ref pointing at them. Like:\n>\n> git log ..HEAD --simplify-by-decoration\n\nNit: dashed options come first and then revs and then pathspecs.\n\n> I think (3) matches what you're trying to do the best. You can't say\n> \"just tags\" for the decoration, though, so you'll see branch tips as\n> well. There's been some discussion about allowing specific decorations,\n> but nothing merged yet.\n"},{"id":"325446","messageId":"20170802173411.tu7wyuehcktxge6o@sigill.intra.peff.net","threadId":"46499","inReplyTo":"xmqqa83idjlj.fsf@gitster.mtv.corp.google.com","subject":"Re: Git log --tags isn't working as expected","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-02T17:34:11Z","receivedAt":"2017-08-02T17:34:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 02, 2017 at 09:23:36AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > 3. Use --simplify-by-decoration to show a particular range of commits,\n> > but limit to ones that actually have a ref pointing at them. Like:\n> >\n> > git log ..HEAD --simplify-by-decoration\n> \n> Nit: dashed options come first and then revs and then pathspecs.\n\nWell, sort of. It does work just fine, and always has. I always thought\nwe were following the GNU-style liberal option ordering.\n\nBy the way, I noticed something funny that I forgot to mention:\n\n git log --tags=does-not-exist\n\nshows HEAD, because the logic to kick in the default only asks \"were we\ngiven any refs to start the traversal?\". I think it probably should\nconsider a wildcard with no matches to override the default, and show\nnothing.\n\nI haven't decided if it should be empty-but-success, or give an error.\nAnd if an error, if it is \"you tried to give me refs, but they showed\nnothing\" or \"you gave me a wildcard that matched nothing\". The\ndistinction matters for:\n\n git log --tags=does-not-exist --tags=does-exist\n\nwhich currently allows the empty wildcard to be a noop.\n\n-Peff\n"},{"id":"325475","messageId":"xmqqd18dsoi1.fsf@gitster.mtv.corp.google.com","threadId":"46499","inReplyTo":"20170802173411.tu7wyuehcktxge6o@sigill.intra.peff.net","subject":"Re: Git log --tags isn't working as expected","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-02T20:28:38Z","receivedAt":"2017-08-02T20:28:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> By the way, I noticed something funny that I forgot to mention:\n>\n> git log --tags=does-not-exist\n>\n> shows HEAD, because the logic to kick in the default only asks \"were we\n> given any refs to start the traversal?\". I think it probably should\n> consider a wildcard with no matches to override the default, and show\n> nothing.\n>\n> I haven't decided if it should be empty-but-success, or give an error.\n\nI agree. The same for --branches, --glob, etc. I'd say it should\nbehave just like \"git log HEAD..HEAD\".\n\n\n"},{"id":"325485","messageId":"20170802221512.zvhaow326jq4vucc@sigill.intra.peff.net","threadId":"46499","inReplyTo":"xmqqd18dsoi1.fsf@gitster.mtv.corp.google.com","subject":"Re: Git log --tags isn't working as expected","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-02T22:15:12Z","receivedAt":"2017-08-02T22:15:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 02, 2017 at 01:28:38PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > By the way, I noticed something funny that I forgot to mention:\n> >\n> > git log --tags=does-not-exist\n> >\n> > shows HEAD, because the logic to kick in the default only asks \"were we\n> > given any refs to start the traversal?\". I think it probably should\n> > consider a wildcard with no matches to override the default, and show\n> > nothing.\n> >\n> > I haven't decided if it should be empty-but-success, or give an error.\n> \n> I agree. The same for --branches, --glob, etc. I'd say it should\n> behave just like \"git log HEAD..HEAD\".\n\nThanks for confirming. That's the way I lean, too. And I found some\nrelated tests for rev-list in t6018 that expect that, too (but are\ncurrently marked to fail).\n\nI'll send some patches in a minute, but I'll start a new thread, as\nwe've drifted off-topic for this one.\n\n-Peff\n"}]}