4 ms·
disclaimer: I was one of the BitKeeper developers in 2003 > Actually, they were just lucky enough that someone wasn't able to break into the main BitKeeper rep
by wscott 8y ago
disclaimer: I was one of the BitKeeper developers in 2003
> Actually, they were just lucky enough that someone wasn't able to break into the main BitKeeper repository.
That is kinda the point of BitKeeper (and yes git as well). The "main" repository is just a convention and everybody has a copy of it. If you changed a line of code in the history then the checksums wouldn't match and this checksum difference would propagate to all following csets. BitKeeper would give an error when talking to the server with this change.
This was actually one of our complaints about git. It is entirely too trusting of blobs of data sent from another git repository. Files are stored and indexed by the SHA1 hash, but that hash is not revalidated when files are read again in the future. We could mangle git objects and then git would checkout bad files without complaining. This would even happen for objects sent over the wire. Only the enclosing checksum is validated but the corrupted objects were not detected. A 'git fsck' would notice, but this is really expensive so rarely used.
It has been a long time, so git may have improved.