[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: intrinsic vs extrinsic identifier: toward more robustness?
From: |
Simon Tournier |
Subject: |
Re: intrinsic vs extrinsic identifier: toward more robustness? |
Date: |
Mon, 06 Mar 2023 14:42:39 +0100 |
Hi,
On Mon, 06 Mar 2023 at 13:22, Maxime Devos <maximedevos@telenet.be> wrote:
>>> For git-fetch, the value of the 'commit' field is intrinsic (except when
>>> it's a tag instead).
>>
>> No, it is imprecise. The exception is *not* label tag as value for the
>> ’commit’ field but the exception is Git commit hash as value.
>
> Are you referring to the fact that currently, the 'commit' field usually
> contains a tag name, and that it containing a commit is the exception?
Yes.
> If so, that doesn't contradict my claim.
There is no contradiction but imprecision.
> I do not see how making a list of all identifiers helps with robustness
> -- you need the object the identifiers point to, not the identifier itself.
If you have the identifiers, you have a chance to find again the
content. For example, in addition to NAR+SHA256, we could also store
Git+SHA1 or plain SHA256 or something else. It would help in exploiting
other content-address systems. For instance, SWH stores,
"checksums": {
"sha1": "3a48fbd0a69c7875dc18bd48a16da04d1512ed47",
"sha1_git": "69cb76019a474330e99666f147ecb85e44de1ce6",
"sha256":
"e62e0f13f9025642a52f9fcb12ca0c31d5e05f78e97224f55b3d70d47c73b549"
},
and maybe ’sha256_nar’ soon. Somehow, we have a list of mirrors so why
not similarly having a list of intrinsic identifier.
> You are hashing the 'hello-2.12.1' directory
Thanks! Having the noise too close and I missed the obvious. :-)
Cheers,
simon