Hi, thanks for the responses, I get the picture. Some comments below still. On Sun, Nov 13, 2011 at 7:27 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > Hi Vinassa, > > vinassa vinassa wrote: > > > I am wondering about how git behaves currently, if I kinda win the > > lottery of the universe, and happen to create a commit with a SHA-1 > > that is already the SHA-1 of another commit in the previous history. > > However improbable. > > That would be great! You could definitely get an academic paper out > of it. > > > Would that be detected, so that I could just add a newline, and then > > commit with a different resulting SHA-1, > > would I just lose one of those commits (hopefully the new one), would > > I end up with a corrupted repository? > > I suspect that one of the two commits would "win" the right to be > shown by commands like "git log". A commit made after one of the > commits participating in the hash collision might be stored as a delta > against the wrong one in the pack, producing errors when you try to > access it (which is good, since it helps you find the hash collision > and you can get a paper and prizes). After cashing in the prizes, I would be able then to git reset --soft, add a newline, make another commit and go on with my work, right? No screw up big enough to demand restoring from backups. > Though I haven't tested. It would be nice to have an md5git (or even > truncated-sha1-git) program to test this kind of thing with. Yes, would be nice. I'll try to see if I can wrap my mind around the test infrastructure. > Thanks and hope that helps, > Jonathan Thank you for your patience, I understand I should not worry about this, but this has made me even more curious about what would happen.. Vinassa -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html