* Git log --tags isn't working as expected @ 2017-08-02 7:41 Richard Jones 2017-08-02 8:32 ` Jeff King 0 siblings, 1 reply; 6+ messages in thread From: Richard Jones @ 2017-08-02 7:41 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git log --tags isn't working as expected 2017-08-02 7:41 Git log --tags isn't working as expected Richard Jones @ 2017-08-02 8:32 ` Jeff King 2017-08-02 16:23 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: Jeff King @ 2017-08-02 8:32 UTC (permalink / raw) To: Richard Jones; +Cc: git 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git log --tags isn't working as expected 2017-08-02 8:32 ` Jeff King @ 2017-08-02 16:23 ` Junio C Hamano 2017-08-02 17:34 ` Jeff King 0 siblings, 1 reply; 6+ messages in thread From: Junio C Hamano @ 2017-08-02 16:23 UTC (permalink / raw) To: Jeff King; +Cc: Richard Jones, git 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git log --tags isn't working as expected 2017-08-02 16:23 ` Junio C Hamano @ 2017-08-02 17:34 ` Jeff King 2017-08-02 20:28 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: Jeff King @ 2017-08-02 17:34 UTC (permalink / raw) To: Junio C Hamano; +Cc: Richard Jones, git 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git log --tags isn't working as expected 2017-08-02 17:34 ` Jeff King @ 2017-08-02 20:28 ` Junio C Hamano 2017-08-02 22:15 ` Jeff King 0 siblings, 1 reply; 6+ messages in thread From: Junio C Hamano @ 2017-08-02 20:28 UTC (permalink / raw) To: Jeff King; +Cc: Richard Jones, git 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". ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git log --tags isn't working as expected 2017-08-02 20:28 ` Junio C Hamano @ 2017-08-02 22:15 ` Jeff King 0 siblings, 0 replies; 6+ messages in thread From: Jeff King @ 2017-08-02 22:15 UTC (permalink / raw) To: Junio C Hamano; +Cc: Richard Jones, git 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-08-02 22:15 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-02 7:41 Git log --tags isn't working as expected Richard Jones 2017-08-02 8:32 ` Jeff King 2017-08-02 16:23 ` Junio C Hamano 2017-08-02 17:34 ` Jeff King 2017-08-02 20:28 ` Junio C Hamano 2017-08-02 22:15 ` Jeff King
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).