From: Eli Schwartz <eschwartz@archlinux.org>
Date: Mon, 25 Jan 2021 00:32:17 GMT
Subject: gitattributes export-subst and software versioning
Message-ID: <7418f1d8-78c2-61a7-4f03-62360b986a41@archlinux.org>

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