Periodically, I wonder if there is some better way for managing tagged
releases for software in git. Current state of the art seems to be
"write a custom Makefile that takes a version and seds out the existing
version, then runs git tag for you". Inelegant solutions also abound;
people release code that does not build properly unless you build it
from a git checkout so it can run git describe. (There are half a dozen
individually popular but mutually exclusive python ecosystems for this,
in fact, all of them varying degrees of broken.)
git does have a way to automatically insert metadata via the
export-subst attribute on a file, but it's very awkward to use and you
cannot get much info out of it.
# get tags into a file, only on exact match:
$ cat VERSION
$Format:%d$
$Format:%D$
$ git archive HEAD | bsdtar -xOf - VERSION
(HEAD -> master, tag: 1.0)
HEAD -> master, tag: 1.0
With sufficient regex, you can get a release out of this, but it doesn't
work if you try getting an autogenerated tarball for a commit that isn't
exactly a release.
$ git commit --allow-empty -m ...
$ git archive HEAD | bsdtar -xOf - VERSION
(HEAD -> master)
HEAD -> master
I think it would be much, much nicer if there was a format placeholder
for git describe.
It doesn't even need option support -- the default output in most cases
could be a replacement for or fall back to existing invocations of the
"git" program, followed by post-processing with e.g. "sed".
However, the existence of current pretty formats such as %C() or
%(trailer:options) implies that options could be passed in a
git-describe format too. e.g. %(describe:--long --tags --match="v*")
Thoughts?
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
