Am Montag, dem 03.01.2022 um 20:07 +0100 schrieb zimoun: > This is somehow intrinsic* because public-inbox uses Message-ID as URL. > Therefore, using emacs-notmuch, you just have to search for > id:86y243kdoo....@gmail.com for instance. > > *intrinsic: no it is not intrinsic but self-contained. :-) I am very happy with my mail reader not showing Message IDs for the most part, but fair enough, I'll extend that courtesy to you and make it do so.
In any case, I am not sure what I'm missing from those messages here. We both agree, that Guix and Git use different (S, H, F) with S being the serializer, H a cryptographic hash function and F a formatter, for their fundamental operations. And that while Guix can produce git hashes "internally" (I'm pretty sure it just calls to libgit, but it's fine if it doesn't), it does not use them for anything meaningful in its own logic. In particular, Guix content addressing scheme is based on SHA-256 NAR hashes, which ought to be robust enough for anything that relies on content addressing. > > Anyway, the point here is a rather simple one that you can base on > > your own explanations. Due to the different ways Guix and Git > > filter, serialize and hash content, you can have two objects O and > > O', such that Git hashes O and O' differently, but Guix does not, and > > similarly two objects O and O' such that Guix hashes them > > differently, but Git does not. Finding particular values for O and > > O' would in some cases be computationally expensive, especially if > > you want to force a hash collision in SHA-256 instead of reusing the > > same files but attaching a different commit message, but > > theoretically possible, and if theoretic possibilities is something > > you want to base your policies on, that is a thing to consider. > > Collision with hashing functions does not mean that the hash does not > *only* depend on the content. Collision means that 2 contents provides > the same hash. The final hashes only depends on the content, whatever > the serializer is and as weak as the hashing function is. That's not the case I'm making here. The case I'm making is that Git considers some content content, which Guix does not consider content. If I push the same file to two branches, once with the commit message "Hello Mark" and once with "Hello Simon", they're the same file to Guix, but different files to Git. > > > I'm not trying to stoke fear, I'm arguing that "raw string in <git- > > reference> for robustness" is a bad take for a multitude of > > reasons. > > 1) No one is advocating to replace tomorrow all by “Git SHA-1 commit > hash in <git-reference>”. Instead, people exposed what are the > motivations to do so, what it would fix, and so on. > > 2) I am still failing to understand your multitude bad reasons. Yes > for sure, introducing more intrinsic values is not straightforward, > socially and about toolings, but I have not read multitude > fundamentally bad reasons. Anyway. I think you're missing an important section of the exchange between messages 867dbmi7pf....@gmail.com and 3d448fe42f0c43574db96fa26aecd7da5fd5a95d.ca...@gmail.com concerning alternative styles, which you've since ignored. My issues with the proposed style are: 1. It is inconsistent, choosing both to trust and not trust a tag simultaneously. 2. It does not communicate anything about that choice to the reader. 3. It enables a particular class of "Tricking Peer Review" style problems. 4a. The issue it tries to address is mostly a social one. 4b. Even if content addressing solves it, SHA-1 is a poor hash and likely to introduce a similar robustness problem anyway. Once again, there are tangible benefits to using a (let-bound) commit inside a <git-reference>, particularly if you have a strong reason to believe that an upstream might be unreliable. However, virtually all of these go down the drain if you do not do so in tandem with git- version. Cheers
