Re: Git commit hash clash prevention

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Oct 2, 2008, 15:39 UTC
Message-ID: <alpine.DEB.1.00.0810021735410.22125@pacific.mpi-cbg.de.mpi-cbg.de>
In-Reply-To: <m3prmjqeq8.fsf@localhost.localdomain>

Hi,

On Thu, 2 Oct 2008, Jakub Narebski wrote:

Show 17 quoted lines

> martin f krafft <madduck@madduck.net> writes:
> 
> > 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?
> 
> Cannot happen in practice.
> 
> But just in case git trusts object it already has in repository over
> object which just got fetched (or pushed).

Oh, maybe the most important part: both David and Jane would have to rewrite their respective history, changing the respective commits in a simple way (such as adding a space to the first line of the commit message or some such). Then, Git is changed to not accept that particular SHA-1 (we'd introduce a black "list").

All in all, it would be like a borked commit; not really easy to fix, but the world would not stop turning because of it.

Ciao, Dscho