Re: On raw strings in <origin> commit field

[Vagrant Cascadian <vagrant@debian.org>]

On 2022-01-03, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant@debian.org> skribis:
>
>> 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
>
> What does ‘git checkout’ do when passed such a string?  Does it ignore
> the tag part?

Technically, I have not tried it where the tag no longer exists, but
when the tag does exist, it checks it out. If the tag is moved or not
longer exists and git does not handle that well, the fallback can be to
the full commit id, e.g. the part without the vX.Y.Z-N-g, as it is the
same as a commit ID.

This at least documents both the tag at the time the committer updated
the guix package, as well as the commit ID, with the ability to somewhat
gracefully fall back to the raw commit ID.

I daresay, it seems like the best of both worlds, with the main downside
of being a little verbose.


>> 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".
>
> For SWH, we need either a tag or a commit ID.

The commit id can be programatically derived from the git describe
format, if you know in fact it is the git describe format with the
appropriate --long and --abbrev=41 arguments.


live well,
  vagrant