git/list[1] front-page[2] threads[3] people[4] search[5] about
 

gitattributes export-subst and software versioning

From
Eli Schwartz <eschwartz@archlinux.org>
Date
Jan 25, 2021, 00:32 UTC
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
Next: René Scharfe
Message 1 of 27 in “gitattributes export-subst and software versioning”
  1. Eli SchwartzJan 25, 2021
  2. René ScharfeFeb 8, 2021
  3. Junio C HamanoFeb 8, 2021
  4. Eli SchwartzFeb 9, 2021
  5. Junio C HamanoFeb 9, 2021
  6. René ScharfeFeb 14, 2021
  7. René ScharfeFeb 14, 2021
  8. 1/2 pretty: add %(describe)René Scharfe, Feb 14, 2021
  9. 2/2 pretty: add merge and exclude options to %(describe)René Scharfe., Feb 14, 2021
  10. Jeff KingFeb 17, 2021
  11. René Scharfe.Feb 28, 2021
  12. Ævar Arnfjörð BjarmasonFeb 28, 2021
  13. René Scharfe.Mar 2, 2021
  14. René Scharfe.Mar 6, 2021
  15. Eli SchwartzFeb 16, 2021
  16. Ævar Arnfjörð BjarmasonFeb 16, 2021
  17. René Scharfe.Feb 16, 2021
  18. Junio C HamanoFeb 16, 2021
  19. Ævar Arnfjörð BjarmasonFeb 17, 2021
  20. René Scharfe.Feb 28, 2021
  21. Ævar Arnfjörð BjarmasonFeb 17, 2021
  22. Junio C HamanoFeb 17, 2021
  23. René Scharfe.Feb 28, 2021
  24. René Scharfe.Feb 28, 2021
  25. René Scharfe.Mar 2, 2021
  26. René Scharfe.Mar 2, 2021
  27. René Scharfe.Mar 2, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.