Also I would be interested to know why KDE don't use something like GitHub or BitBucket? It would be cheaper for the organisation, and they could still setup web hooks to get notifications of commits.
That said, we did originally try to work with Gitorious, but that didn't come to pass for a variety of reasons. Here's a small writeup of our journey back then, some of the parts discussed there have since been swapped out or fleshed out further: https://news.ycombinator.com/item?id=2972107
Because no, the data isn't all in git. For example, which set of credentials was used to write which piece of data to a repo isn't stored in git, it's logged by the authentication system in front of git.
This is in fact the main selling point of DSCMs - everything's a repo, repositories can (provided access) exchange data bidirectionally, and data can take all sorts of interesting routes from A to B involving as many repositories inbetween as you'd like.
Negotiating the actual write access to a repo happens entirely outside of git. That's really a good chunk of what software like Gitorious, GitHub or gitolite do, and then on top of that you get into the collaboration features and stuff.
It may not be kosher, and I don't think the porcelain supports it, but I think you could write a remote that only accepts commits if they are all signed by someone on a trusted list. This would probably mess up a lot of workflows though, since if person A writes some commits, person B rewrites them to sign them and then pushes them to the repo, then when person A pulls the commits "they" created they would actually be different commits.
If we were willing to take that hit though, I think it should also be possible to modify git to permit multiple signatures on a single commit. Users could take a signed commit, append their signature too it (well, technically not append. Signatures are in the middle it seems) and then push it or pass it on to others to sign. This would only allow a single commit to go through the system at once (since commits after the first would need to be rewritten, invalidating previous signatures) but on the other hand it would let you create an integration server that only accepts commits that have been signed by some number of trusted code-reviewers, while still keeping all of that information in git. So long as trusted code-reviewers all signed off on it, who actually sent it to the integration server probably would not be particularly important. Such a modification to git would probably be extremely un-kosher of course...
As for Hetzner: The git.kde.org master server isn't at Hetzner, nor are a bunch of the mirrors. Our infra is pretty distributed and eclectic as far as hosting locations go, partly because a lot of the resources are donated from all over. We don't "support" any hoster in particular.
A SYNCHED COPY IS NOT A BACKUP.
This includes:
- git
- svn
- Dropbox
- RAID (of any kind)
If you don't believe this, please reconcile everything you've learned about backups. More specifically, if you treat any VCS or dropbox as your only backup system, STOP RIGHT NOW and at least get something that's intended to be a backup, such as SpiderOak in backup mode.