3 ms·

An amazing thing about git (and other DVCSs as well) is that even if a much more serious catastrophe had happened (e.g., if a nuclear bomb had struck the KDE da

by nathell 14y ago

An amazing thing about git (and other DVCSs as well) is that even if a much more serious catastrophe had happened (e.g., if a nuclear bomb had struck the KDE datacenter), it would probably still be possible to reconstruct (an approximation of) the master repo, simply due to the fact that it was fully cloned on hundreds of developers' machines worldwide. Linus Torvalds once coined an adage that "real men don't make backups. They upload it via ftp and let the world mirror it." Well, the FTP bit isn't true anymore, but otherwise DVCSs have enabled this for mere mortals.

tjoff 14y ago
Any VCS would be equivalent to the ftp...
- jlgreco 14y ago
  The ftp mirror most likely has tarballs of the source of all recent versions. Any VCS would not give you the same protection, unless you assume that there are a bunch of developers that keep checkouts of every major version (with DVCS, that would certainly be the case. Otherwise? I don't think so.)
  - tjoff 14y ago
    Good point.
sho_hn 14y ago
In terms of how this would be done practically: We did have intact gitolite logs I believe, which record the credentials involved in pushing any ref and what they're getting updated to, so we'd have known what data we would have needed to locate and who we could contact to provide it. And since the commit hashes describe their content, there wouldn't have been a risk of manipulated data.
- jedbrown 14y ago
  Presumably the mirrors also did not run an aggressive 'git gc' immediately after 'git remote update', so they would still have non-corrupt commits in the object store, in which case you could recover by "just" resetting any corrupt refs.
rmc 14y ago
There are security considerations with that approach. Someone could have edited their copy of the repo and put in any code they wanted. If you presume the person isn't lying, and trust their code, you've just been back doored.
- XorNot 14y ago
  Git uses a rolling SHA-1 checksum which describes both content and commit logs. As long as they had the hashes of the commits, then they can be sure that anyone who has a chain of commits leading to that hash has the real content.
  - rmc 14y ago
    Yeah, but now you need to know the commit hash for all the branches. Basically, you need a form of backup. But this problem presumes you don't have much of a backup.
    - XorNot 14y ago
      Oh sure, but at the end of the day some developer or group of developers is in charge of those repositories, and considered a trusted person (or effectively is). Between them and the large number of developers who would have copies of the repo, reaching consensus on what the "true" repo was - while not easy - could be done in a secure fashion due to the hashes. You wouldn't have people declaring "no it's totally it" and not being able to verify.

by nathell 14y ago

tjoff 14y ago

Any VCS would be equivalent to the ftp...

jlgreco 14y ago
The ftp mirror most likely has tarballs of the source of all recent versions. Any VCS would not give you the same protection, unless you assume that there are a bunch of developers that keep checkouts of every major version (with DVCS, that would certainly be the case. Otherwise? I don't think so.)
- tjoff 14y ago
  Good point.

sho_hn 14y ago

In terms of how this would be done practically: We did have intact gitolite logs I believe, which record the credentials involved in pushing any ref and what they're getting updated to, so we'd have known what data we would have needed to locate and who we could contact to provide it. And since the commit hashes describe their content, there wouldn't have been a risk of manipulated data.

jedbrown 14y ago
Presumably the mirrors also did not run an aggressive 'git gc' immediately after 'git remote update', so they would still have non-corrupt commits in the object store, in which case you could recover by "just" resetting any corrupt refs.

rmc 14y ago

There are security considerations with that approach. Someone could have edited their copy of the repo and put in any code they wanted. If you presume the person isn't lying, and trust their code, you've just been back doored.

XorNot 14y ago
Git uses a rolling SHA-1 checksum which describes both content and commit logs. As long as they had the hashes of the commits, then they can be sure that anyone who has a chain of commits leading to that hash has the real content.
- rmc 14y ago
  Yeah, but now you need to know the commit hash for all the branches. Basically, you need a form of backup. But this problem presumes you don't have much of a backup.
  - XorNot 14y ago
    Oh sure, but at the end of the day some developer or group of developers is in charge of those repositories, and considered a trusted person (or effectively is). Between them and the large number of developers who would have copies of the repo, reaching consensus on what the "true" repo was - while not easy - could be done in a secure fashion due to the hashes. You wouldn't have people declaring "no it's totally it" and not being able to verify.