And I'm really glad they're like this.
Putting every eggs in one closed-source service seems trendy these days, but in the long run it's always a huge issue.
And it's not just that you're using closed software -- you're using a closed service. Even when we were considering going with Gitorious.org, which is open source, that still left service-related concerns to address: Can you get your data out conveniently?
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.
No. Signed commits sign the commits, and because git is a DSCM, the person who created a commit doesn't need to be the person that put the commit into the repository (in fact, git further differentiates between author and committer, which is useful for "who wrote the patch vs. who put it in a commit object", but that's in the repo data).
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.
Hmm. Going from how commits are formatted to include signing, I think it should be possible to strip signatures and re-add them. This would create a new commit object of course, so if you had multiple commits that needed to be pushed you would have to actually need to re-write the rest of the commits to have different parents...
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...
Aye. That's probably not a massive ask, I'm wondering more right now if current versions of git with with gpg would gracefully handle multiple signatures being present. If it couldn't be done in a backwards compatible fashion, then it's probably not worth much further consideration.
There are open alternatives to GitHub - we managed to put one together we're reasonably happy with, after all - but unfortunately the buck right now tends to stop at the hardware.
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.
