martin f krafft wrote: > the other day during a workshop on Git, one of the attendants asked > about the scenario when two developers, Jane and David, both working > on the same project, both create a commit and the two just so happen > to have the same SHA-1. I realise that the likelihood of this > happening is about as high as the chance of <insert witty joke > here>, but it *is* possible, isn't it? Even though this is thus > somewhat academic, I am still very curious about it. > > What happens when David now pulls from Jane? How does Git deal with > this? There are two cases: * The commits are exactly identical. This won't happen in your scenario, but is still theoretically possible if you commit the same tree with the same author info, timestamps, etc. on two different machines. Then there is no problem, because they really are the same. * They're not identical, but there is a hash collision. Git will become very confused because it only ever saves one of them. (I suppose it'd "only" corrupt the DAG if the two are commits, but in the general case a commit could collide with a tree etc.) However, the expected number of objects needed to get a collision is on the order of 2**80 (http://en.wikipedia.org/wiki/Birthday_attack), and since there are (very roughly) 2**25 seconds in a year and 2**34 years in the age of the universe, that still leaves you with 2**21 ages of the universe to go. (I hope I did the counting right...) > I imagine it'll be able to distinguish the two commits based on > metadata, but won't the DAG get corrupted? No, it does not distinguish between objects in any way but the SHA1. - Thomas -- Thomas Rast trast@xxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
