Re: On raw strings in <origin> commit field

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

On 2021-12-28, Liliana Marie Prikler wrote:
> Consider a package being added or updated in Guix.  At the time of
> commit, we have the tag v1.2.3 pointing towards commit deadbeef.  We
> therefore create a guix package with version "1.2.3" pointing to said
> commit (either directly or indirectly).  At this point, one of the
> following holds:
>   (1) Guix "1.2.3" -> upstream "v1.2.3" -> upstream "deadbeef"
>   (2) Guix "1.2.3" -> upstream "deadbeef" <- upstream "v1.2.3"
> From either, we can follow that Guix "1.2.3" = upstream "v1.2.3".  If
> upstream keeps their tags around, then both forms are equivalent, but
> (1) is more convenient; it allows us to derive commit from version,
> which is often done through an affine mapping.

How about using the output of git describe, which can unambigously
include the most relevent tag, the number of commits since that tag, and
the commit hash:

  $ git describe --long --abbrev=41
  v1.3.0-13278-g60661adfb8ffa28e1acfcfea27c6cc2fc70f88fe

  $ git describe --long --abbrev=41 v1.3.0
  v1.3.0-0-ga0178d34f582b50e9bdbb0403943129ae5b560ff

I *think* I've used such git references in the commit field of packages
before, and guix seemed fine with it. Occasionally, I've seen git
describe pick an odd tag to base on. Not sure how it interacts with
software heritage, or multiple tags, or renamed tags... but in theory it
could work, and would allow us to detect tag changes "upstream".


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]