Chances of a sha1 collision are so low that all the git repos in the world combined are still astronomically unlikely to collide at all. You'd need 2^80 git objects to exist for a collision to be likely, which would require roughly 100 quadrillion git repos the size of the linux kernel repo. Storing just the shas of those objects would require 50 yottabytes of disk space, let alone storing the object values.



This kind of system should still not be designed to use shaN. Use multihash so you can upgrade ifwhen collision generation becomes feasible. (As ipfs does.)

joeyh at 2015-05-29T22:50:31Z

jrobb, Olivier Mehani, Screwtape, Lars Wirzenius and 4 others likes this.

What then of collision problems in github's shared backend?
http://stackoverflow.com/questions/4864740/github-repo-corruption-sha1-collision

This appears to have been due to a corrupt repo, so not a legit collision.

Repos can be constructed with what look like colliding objects. Git's "SHA1 COLLISION FOUND" is triggered if 2 objects with the same sha appear to have different sizes or types. This can easily happen due to corruption; flip a bit in the type and a tree object seems to be a colliding blob object.

joeyh at 2015-05-29T23:13:17Z

Christopher Allan Webber likes this.

Thanks @joeyh for the analysis and references. On top of all that, the global namespace would be only commits, not every kind of object, so that further reduces the risk of collision. I feel less concerned now. :-)

Claes Wallin (韋嘉誠) at 2015-05-30T11:39:21Z

Christopher Allan Webber likes this.