Re: gitattributes export-subst and software versioning

From: René Scharfe <l.s.r@web.de>
Date: Feb 8, 2021, 19:46 UTC
Message-ID: <ac1288b8-5cdf-8e1e-702a-815c5fbc2da3@web.de>
In-Reply-To: <7418f1d8-78c2-61a7-4f03-62360b986a41@archlinux.org>

Am 25.01.21 um 01:32 schrieb Eli Schwartz:

Show 30 quoted lines

> 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.

Totally.

Show 9 quoted lines

> 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?

git archive uses the pretty format code for export-subst. It is used by git log and others as well. git describe uses all object flags to find the best description. Simply plugging it into the pretty format code would clash with the object flag use of git log.

And replacing the flags with a commit slab doesn't seem to be enough, either -- I get good results lots of commits, but for some git log with the new placeholder would just show some nonsensical output, as it seems to get the depth calculation wrong for them somehow.

Anyway, we can of course do something like in the patch below. It works, it's easy, it's fast enough for git archive, and it's quite hideous. Hopefully it's bad enough to motivate someone to come up with a cleaner, faster solution.

René

---
 pretty.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/pretty.c b/pretty.c
index 3922f6f9f2..bbfb5ca3e7 100644
--- a/pretty.c
+++ b/pretty.c
@@ -12,6 +12,7 @@
 #include "reflog-walk.h"
 #include "gpg-interface.h"
 #include "trailer.h"
+#include "run-command.h"

 static char *user_format;
 static struct cmt_fmt_map {
@@ -1213,6 +1214,21 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
 		return parse_padding_placeholder(placeholder, c);
 	}

+	if (skip_prefix(placeholder, "(describe)", &arg)) {
+		struct child_process cmd = CHILD_PROCESS_INIT;
+		struct strbuf out = STRBUF_INIT;
+
+		cmd.git_cmd = 1;
+		strvec_push(&cmd.args, "describe");
+		strvec_push(&cmd.args, "--always");
+		strvec_push(&cmd.args, oid_to_hex(&commit->object.oid));
+		pipe_command(&cmd, NULL, 0, &out, 0, NULL, 0);
+		strbuf_rtrim(&out);
+		strbuf_addbuf(sb, &out);
+		strbuf_release(&out);
+		return arg - placeholder;
+	}
+
 	/* these depend on the commit */
 	if (!commit->object.parsed)
 		parse_object(the_repository, &commit->object.oid);
--
2.30.0