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.
