From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 57CEC1F934 for ; Mon, 25 Jan 2021 00:42:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726296AbhAYAj0 (ORCPT ); Sun, 24 Jan 2021 19:39:26 -0500 Received: from mail.archlinux.org ([95.216.189.61]:54886 "EHLO mail.archlinux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725986AbhAYAjZ (ORCPT ); Sun, 24 Jan 2021 19:39:25 -0500 X-Greylist: delayed 378 seconds by postgrey-1.27 at vger.kernel.org; Sun, 24 Jan 2021 19:39:24 EST From: Eli Schwartz DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=archlinux.org; s=dkim-rsa; t=1611534745; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=mtfwKv7AGvI7bH29PuFjvJKoY39KUtn/sSXcqq9M2XA=; b=v9hj9EUzfMQm+2popWPClvgiaf9mEdMQB+EYqdGC1qPB+W44lrREuOdlX0JBTzctpy5I8J wltpuMEYkJZaK07VWGxgOKHZQ4D/3oMVJg5bRvr9agfxMavWmRMpao5JrJZedKksvCnCpg g3CTkz4Tuhabor+ZdXj9Jz73lpcGjtWMrXgj7jKinFbH6srgE3FXZKhHI654FRUqr2i5Bq 5QEo2lag2vbsvbfes5j1uBRamvXZHvuNrZuT+4c/pU8eVje6JoqaWu+8vvwntfZznhZl0p dkUxzm1ymZiIT9wVXGC5ccLd877OQmXic6fy1HDo+D7YgiF5vqBM6moq3UOd4p9Yy95Krt zucSP2MgARSzAMKWiQEL/jnrwE2W6qVotJeklIPCBmZV5YUGGzwdYaqALfLluN026iXgc2 QvauPpuDDb/7JWDTNWieFF19xWKXNeO3Rho6eDiN61j6fkgSNF7AESBEJY7N3IsttMAlk/ kMyp2SJ6OWg0el+Ff8Qpf4PT54baDTBr574PKWJtERxKkeb5TfK5/YOj0dL8JNgln1THnS 7/68Kau5Fw8VflmzdXOOS528pVV8KZt3RvkJuvF6u0CICQBjY3y3pOoxJDJ55h9fXqUO6e qHLQ5xvy6w4XF/tZaU7nS8IqSevw23t61uT6p7ygJpxpGP+FIrxQs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=archlinux.org; s=dkim-ed25519; t=1611534745; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=mtfwKv7AGvI7bH29PuFjvJKoY39KUtn/sSXcqq9M2XA=; b=4opjyK8NQAsYyluRnczTTkeMlTGLaFIE42/5VE6HNO98pQjuXvzRZOREbGaoV6Hce2/Yo/ uJ1PEQ+ZLC8RVABw== To: git@vger.kernel.org Subject: gitattributes export-subst and software versioning X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <7418f1d8-78c2-61a7-4f03-62360b986a41@archlinux.org> Date: Sun, 24 Jan 2021 19:32:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US-large Content-Transfer-Encoding: 8bit Authentication-Results: mail.archlinux.org; auth=pass smtp.auth=eschwartz smtp.mailfrom=eschwartz@archlinux.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.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