Log in


Some notes on git hosting software

« previous entry | next entry »
1st Dec 2011 | 19:43

My colleague Ben Harris has been working on a configuration management system, based on my git-deploy idea with added cryptographic security. Ben's "starling" system will ensure that servers will only deploy configurations that have been gpg signed by a trusted sysadmin.

We have not yet got a git repository hosting setup, though it is an obviously required part of the system. So this week I have been looking at what software is out there. To make it interesting we would like to go beyond the usual corporate deployment and see if we can do something useful as a university-wide service. "Something useful" unpacks into the following shopping list of features, which I am posting here in case anyone outside the CS has good suggestions.

Read/write access via ssh, with per-repository and per-branch access controls. Browse repositories via the web.
Delegated access control
We would like to delegate repository creation and management to groups (such as the computing service itself, other University departments, research groups, etc.) and we would like group managers to be able to delegate repository access control to repository managers.
Repositories for individuals
Each user should have an automatically provisioned group of their own (like github).
Public and private repositories
Repository managers should be able to allow anonymous read-only access via the git protocol and the web repository browser.
Authenticated browsing
Users who have read access to a repository should be able to browse it via the web.
External collaborators
Allow repository managers to give access to users without University accounts.

What software can do this for us? Here's a quick review of the candidates that I know of. Any other suggestions are welcome. (I have not included gitosis since it was made obsolete by gitolite.)

The obvious outsourcing option. Has all the features we want, I think, though we would have to pay, and they don't advertise prices for the scale we would need just for the computing service.
A set of perl scripts that just does access control to repositories via ssh. Management is done by commits to an admin repository. This model implies a petty bureaucracy of people who have commit access to the admin repository. For delegated management we would need a gitolite install per group. It doesn't support delegating access control decisions per repository. Individual setups are probably not feasible - point them at github instead? Web access is anonymous-only. External collaborators are easy since the repoman has complete control over which ssh keys have what access.
The web-based code review tool developed for the Android project. As such its focus is on a feature we don't particularly care about. A big Java program with its own ssh and git implementations. It allows access control delegation per repository, but it does not allow delegation of repository creation. It supports web access controls and has hooks for web single sign-on, by default using OpenID but the "siteminder" support can probably be used with Raven.
Affero-GPL source for a github competitor. Big Ruby-on-Rails app. Designed to allow users to do their own access control and set up their own groups. Big downside is lack of support for private repositories (but see this merge request). Bonus wiki feature.

I think the choice is between gitolite and gitorious. Gitolite has the advantage of simplicity at the cost of several desirable features. Gitorious would require us to maintain a fork.

| Leave a comment | Share

Comments {14}


from: 11011110
date: 1st Dec 2011 19:52 (UTC)

Something like this would be very useful to me, too, so your roundup of solutions looke quite helpful. But I'm curious: why did you settle on git, when there are so many other alternatives (svn, mercurial, whatever)?

Reply | Thread

Tony Finch

from: fanf
date: 2nd Dec 2011 12:23 (UTC)

We're using subversion already for source code, but it's far too slow and no use as the basis for a configuration management system. Mercurial is probably OK, but it doesn't have the mindshare and momentum of git, and its repository design is considerably worse. See my earlier git-deploy article for more of the configuration management rationale.

Reply | Parent | Thread

Ben Harris

from: bjh21
date: 2nd Dec 2011 13:01 (UTC)

For Starling's purposes, I wanted to avoid people (myself included) having to learn an otherwise rare DVCS. That effectively meant that if possible I wanted to use Subversion, Bazaar, or Git. Of those, Git has the best support for signed tags, is friendly towards the idea of having lots of branches, and is generally designed on the assumption that you'll be messing around with its internals (which I am). For source code control, I'd prefer either of the others, but as a toolkit from which to build a configuration-management system, Git seems much superior.

Also, Tony had designed and half-written git-deploy already, which gave me something to build on and someone to discuss ideas with.

Reply | Parent | Thread