3 ms·

AFAIK thanks to the hashing used with git there is very little chance of corruption. The filenames are 32bit hashes so the probability of collision between the

by dalore 15y ago

AFAIK thanks to the hashing used with git there is very little chance of corruption. The filenames are 32bit hashes so the probability of collision between the hashes of two given files is 1 / 2^32. The probability of collisions between any of N given files is (N - 1) / 2^32.

weaksauce 15y ago
I meant a state that the repo does not like and not really corrupted. say you push your changes and someone else pushes their changes and you both try to move the head and you get a dropbox conflict. You would have to go and fuss with the refs and the refs log to find out where the other head should have gone and manually change things that you shouldn't have to. Not the end of the world but for a guide that is seemingly for beginners why hassle with it when there is a free way that is easier to do what they are trying to accomplish?
maxs 15y ago
Just to correct you: the probability is _much_ bigger than (N-1)/2^32. See the birthday problem: http://en.wikipedia.org/wiki/Birthday_problem http://en.wikipedia.org/wiki/Birthday_problem
- weaksauce 15y ago
  The search space of the object name is a sha1 and is 40 characters long and not 32 bits so it's quite a bit larger than the op was talking about(it's actually 160bits). see: http://book.git-scm.com/1_the_git_object_model.html http://book.git-scm.com/1_the_git_object_model.html
codys 15y ago
Repo "corruption" via dropbox does not need a SHA-1 collision. Git uses other files for tracking things, for example: .git/refs/* and .git/HEAD, which point to particular objects (via SHA-1 hashes). If one of these has a "confilicted change" (via dropbox), one person has the HEAD of the repo (or some other branch) pointing to a commit they do not expect it to point to. Even more interesting is when one person wins HEAD and the other wins it's paired branch in .git/refs/ . Further, git does occasional packing of the object repository. 2 People attempting to pack the object repository when it contains different items might produce interesting results.

by dalore 15y ago

weaksauce 15y ago

I meant a state that the repo does not like and not really corrupted. say you push your changes and someone else pushes their changes and you both try to move the head and you get a dropbox conflict. You would have to go and fuss with the refs and the refs log to find out where the other head should have gone and manually change things that you shouldn't have to. Not the end of the world but for a guide that is seemingly for beginners why hassle with it when there is a free way that is easier to do what they are trying to accomplish?

maxs 15y ago

Just to correct you: the probability is _much_ bigger than (N-1)/2^32. See the birthday problem: http://en.wikipedia.org/wiki/Birthday_problem http://en.wikipedia.org/wiki/Birthday_problem

weaksauce 15y ago
The search space of the object name is a sha1 and is 40 characters long and not 32 bits so it's quite a bit larger than the op was talking about(it's actually 160bits). see: http://book.git-scm.com/1_the_git_object_model.html http://book.git-scm.com/1_the_git_object_model.html

codys 15y ago

Repo "corruption" via dropbox does not need a SHA-1 collision. Git uses other files for tracking things, for example: .git/refs/* and .git/HEAD, which point to particular objects (via SHA-1 hashes). If one of these has a "confilicted change" (via dropbox), one person has the HEAD of the repo (or some other branch) pointing to a commit they do not expect it to point to. Even more interesting is when one person wins HEAD and the other wins it's paired branch in .git/refs/ . Further, git does occasional packing of the object repository. 2 People attempting to pack the object repository when it contains different items might produce interesting results.