[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On raw strings in <origin> commit field
From: |
Ludovic Courtès |
Subject: |
Re: On raw strings in <origin> commit field |
Date: |
Mon, 03 Jan 2022 16:51:33 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hello,
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?
> 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.
Thanks,
Ludo’.
- Re: On raw strings in <origin> commit field, (continued)
Re: On raw strings in <origin> commit field, Bengt Richter, 2022/01/01
Re: On raw strings in <origin> commit field,
Ludovic Courtès <=