5 ms·
Since the OP is here, I am confused. In the first section, are you saying that: a) tags can and should be named to include the sha at the end; and b) git com
by Robin_Message 4y ago
Since the OP is here, I am confused.
In the first section, are you saying that:
a) tags can and should be named to include the sha at the end; and
b) git commands silently discard everything before "-g" if what follows is a sha?
I feel like I've missed something as I find b) very surprising. (Consider giving someone the string $LATEST_VERSION_NUMBER-g$MALICIOUS_VERSION_SHA; I can't work out an exact exploit but it seems wrong to only process the SHA.)
- da-x 4y agoI'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