This works OK for 25 people. It is slow as snot for 100 people. Its
not possible for 1000 people. Its utterly garbage for 8000 people. I
know multiple servers with more than 8000 keys enrolled on them. You
can't use ~/.ssh/authorized_keys for this.
Using our own SSHD allows us to have direct control over the entire
authentication process, and map the login system to a database that
can scale to 8000+ keys enrolled on it.
There was also some mild rejection to everyone having the same SSH
username. Some of the Googlers who I talked to in the early days of
Gerrit thought that was ugly. They wanted their own username, because
then it could match the username on their workstation, and they
wouldn't need to configure a username at all. We didn't want to hack
OpenSSH to support what we needed, it would be ugly to distribute the
patches on top of OpenSSH and keep rebasing them as upstream OpenSSH
was developed, not to mention harder to install Gerrit on your own
server. So... we went with our own embedded SSHD.
> Git:
> Why use a Java reimplementation of Git. Wouldn't something like 'git
> push origin HEAD:refs/for/master' still work the same on a regular
> build of Git?
Not really. C Git would actually create the reference
"refs/for/master", which would then block other users from pushing
their own changes to that same name because it would be a
non-fast-forward push. We could use a C Git update hook to block
creation of refs/for/master, but still receive the SHA-1 and update
the reviews. However a non-zero exit status from the update hook to
block creation of refs/for/master would cause an error message to be
sent to the client, which is ugly.
Rather than hack the C implementation to allow a richer interaction
between the hooks and the receive-pack process that is handling the
pack stream and generating the status codes back to the client, we
chose to work with the existing Java implementation that already
supported some of what we needed, and was more flexible because it had
more direct control when everything was running in the same process.
At this point we had also already settled on rewriting the Gerrit web
UI in GWT and the server in Java, so it made sense to embed the Java
implementation of Git for Git operations, rather than forking out to
the C implementation.
> Lastly, while I'm at it: is there a way to receive emailed diffs on a
> successful merge? Sort of what git-commit-notifier does:
> http://bitboxer.de/git-commit-notifier/
You may be able to plug into the change-merged hook on your server:
http://gerrit.googlecode.com/svn/documentation/2.2.0/config-hooks.html#_change_merged
Or monitor the server using stream-events:
http://gerrit.googlecode.com/svn/documentation/2.2.0/cmd-stream-events.html