Re: On raw strings in <origin> commit field

[Ricardo Wurmus]

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

>> And for completeness, let quote Ludo again from the same thread. :-)
>> 
>>         No, I think we should consider always referring to commits
>>         instead of tags.  It’s annoying from a readability viewpoint,
>>         but it would ensure reproducibility.  Even flatpak has this
>>         policy.  :-)
>> 
>>           https://github.com/flathub/flathub/wiki/App-Requirements
> ... 
>
> Fine, I'mma quote flathub for a change.
>> When building from a git tag, both the tag name and the commit id
>> should be specified, like so:
>> 
>>    "tag": "1.0.4",
>>    "commit": "cdfb19b90587bc0c44404fae30c139f9ec1cca5c"
> It's almost as though they know a commit without a tag has no intrinsic
> meaning.  Also, I'm pretty sure flatpak could care less about hashes if
> asked to (unlike Guix, which requires you provide one to be granted
> network access), so the optional by means other than policy SHA-1 hash
> here is not comparable to the required SHA-256 hash we always have.

In the past I’ve also added a comment above the raw commit, stating that
it corresponds to the given version.

I have no strong feelings for or against any of the proposed options.  I
think that using raw commits might not be great for our tooling because
we’re not reusing an existing version string and would need to remember
to update the raw commit as well.  But other than that I don’t find the
raw commit to introduce readability problems for humans.

-- 
Ricardo