[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: git-fetch without a hash
From: |
Simon Tournier |
Subject: |
Re: git-fetch without a hash |
Date: |
Mon, 06 Feb 2023 18:01:31 +0100 |
Hi,
On dim., 05 févr. 2023 at 18:44, bokr@bokr.com wrote:
>> From my understanding, we could have something like,
>>
>> (sha256 (no-hash))
>>
>> where ’no-hash’ would return a string, say
>> "0000000000000000000000000000000000000000000000000000" or whatever else
>> that would satisfy this hypothetical ’sha256’ sanitizer.
> For portability to any hash algorithm that returns a hex string,
> how about letting them hash a zero-length string (which can never
> represent a package tarball or other archive), and using the
> resulting strings as no-hash flags?
Instead of “0000000000000000000000000000000000000000000000000000”, you
are proposing “0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73”
which is the Guix hash of empty.
> $ sha256sum /dev/null
> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /dev/null
$ touch foo
$ guix hash foo
0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73
$ guix hash foo -f hex -H sha256
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Yeah, probably better. :-)
> These strings must be unique for whatever hash algorithm,
> so a short table could be used to recognize them as
> no-hash indicators.
Well, I do not understand “These strings must be unique for whatever
hash algorithm”. What do you mean?
Cheers,
simon