On Fri, 20 Oct 2006, Johannes Schindelin wrote:
On Fri, 20 Oct 2006, Jakub Narebski wrote:
Johannes Schindelin wrote:
On Fri, 20 Oct 2006, Lachlan Patrick wrote:
How does git disambiguate SHA1 hash collisions?
It does not. You can fully expect the universe to go down before that
happens.
Or you can compile git with COLLISION_CHECK
From Makefile:
# Define COLLISION_CHECK below if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# sufficient guarantee that no collisions between objects will ever happen.
You can document your disbelief.
But it does not change a thing. Since v0.99~653, we do not have any
collision check, even if compiled with COLLISION_CHECK.
I had the same disbelief as you about this, however the last time this came up
Linus pointed out something that satisfied me.
any action in git that could create or or recreate an object will not overwrite
an object that it thinks that it already has.
so
if you create a new local file that would conflict and save it, git will accept
your save and throw away the new file.
if you pull from a remote repository and there is a file there that conflicts
with a file you already have it will throw away the new file.
if you pull from a remote repository and someone has hacked it to replace a file
with a bad one, if you already have the good one git will throw away the bad
one.
as a result the worst case is that a new file being checked in doesn't really
get in and when someone checks it out and trys to use it they get the old
contents. In the case of code, it's extremely unlikly that the wrong code will
even compile, let alone do anything remotely close to working correctly. At this
point the fix is to go back to the origional developer to get the correct
version while additional changes are made to git (and remember, that unless this
is a brand new file the prior version is readily available so only the latest
diff needs to be recovered)
so the odds are extremely low and the concequeces of a collision are fairly
minor.
git has (or had) an option to actually check the full contents before throwing
away the new copy instead of just checking the hash (and throwing an error if
the contents don't match), but the performance cost of this is pretty high.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html