Display current git tag if any

[pzehner]

Hello, thanks for this nice package!

You can associate a tag to a commit with git tag <tag name>, which is useful to set human-readable document version (when distributing it). I don't think such tags are currently used by this package. It would be nice if, when the current commit is associated to a Git tag, this tag could be displayed instead of the commit hash.

By instance, on commit #012345 associated with tag 0.1.0, \gitVer would give "0.1.0", \versionBox would give "Manuscript version: 0.1.0 - 2022-08-29 13:41", and the PDF metadata would be "Version 0.1.0".

Git tag can be extracted with git describe --tags --always for the current commit. If the current commit comes after a previous commit associated with a tag, <tag>-<number of commits since the tag>-<current commit hash> is returned. If the project has no Git tag, the current commit hash is returned.

This behavior could be the default, and would be disabled with a package option noGitTag.

[charlesbaynham]

Hi @pzehner ,

Thanks for the feedback! I've actually explicitly disabled that behaviour: my git command is

git describe --match nopenopenope --always --long --dirty --abbrev=6 

. The "nopenopenope" bit is a hack to force git to display the hash and only the hash.

In fact, I think the package used to display tags ages ago before I published it, but I removed it. I'm sure I had a reason for this, but I can't remember what it is... I wouldn't want to change the default behaviour since people might surprised if their documents suddenly start changing, but adding this as an option behind a [useTags] package option would be a nice idea.

If you'd like to implement it as a PR I'd be happy to accept. Otherwise I'll get to it eventually :)

[BjoernLudwig]

Hi guys, I like the package a lot and that's why I browsed the issues. Just my two cents on the suggestion: a git tag can be deleted and then be reapplied to another commit. That is something you cannot detect, when only looking at the tag and the compilation date, as I understand the original suggestion was. So I would recommend to at least add the hash in addition to the hash, or optionally replacing the hash by the tag, as in one option to add a tag and another to then remove the hash, if a tag was found.
As I understand, the current default behaviour should not have been changed anyway, so that's just another remark adding to that.