On Fri, Jan 13, 2023 at 05:06:57PM +0100, Hans Petter Selasky wrote: > OK, if you say so. Though in my mind 46K rebases of millions of commits seem > a lot overhead. Not to discourage you, but you seem to be making statements without a good understanding of how git works. If there is a history rewrite (even one that for some reason goes back millions of commits) all hash calculations will happen exactly once -- on the system of the person who's rewriting the history. After they push it, it's just a bunch of objects that everyone else merely downloads. > However, if history can be edited anyway, why do you need the cryptographic > hash algorithm. Why not use a non-cryptographic one? The answer is, unhelpfully, "because that's how git works." Every commit is a standalone object that references the previous commit, plus includes hashes of all trees, and those include hashes of all blobs. SHA-1 was picked because of its speed and the fact that it guarantees an extremely low potential for collisions (even better with SHA256). As a side-effect, it's easy to calculate the integrity of the entire tree, including its history, by verifying its hashes (this is what git fsck does). Hashes aren't really "cryptographic" anyway (they just happen to be used all over the place in cryptography). It's really just a one-way function to reduce content of arbitrary size to a set of bytes of a determined size (and give a relatively high assurance of it being collision-free). -K
