Re: Git commit hash clash prevention
Show 10 quoted lines
> 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@student.ethz.ch
Thomas Rast <trast@student.ethz.ch>