Re: Git commit hash clash prevention

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@student.ethz.ch