3 ms·
I'll try to clarify. The `<tag>-g<hash>` string is _not_ the name of the tag, it's a string emitted by `git describe` based on the existence of `<tag>` in the h
by da-x 4y ago
I'll try to clarify. The `<tag>-g<hash>` string is _not_ the name of the tag, it's a string emitted by `git describe` based on the existence of `<tag>` in the history.
Of course I'm not suggesting that tag names should include the hash. The existence of the tag `v4.11-rc7` allows other commits to have nicer derived names.
EDIT:
Also to your last inquiry, it may be indeed a surprise that Git resolves `<anystring>-g<githash>` to `<githash>`, but some may argue it's a feature, not a bug :)
- WorldMaker 4y agoAlso, git describe's output is not just <tag>-g<hash>, it is <tag>-<commitcount>-g<hash>. That number of commits since the tag counter can be handy in its own way (such as it is sometimes handy when trying to figure out which branch the <hash> is most likely from). I'm curious if the git resolution algorithm that accepts describe strings also verifies/checks the commit count matches. Glancing at the documentation [1] it says that it specifically matches describe output strings (the docs call it <describeOutput>) and not just "<anything>-g<hash>", so it may actually check the tag existence and verify the commit count. [1] https://git-scm.com/docs/gitrevisions https://git-scm.com/docs/gitrevisions