Git in the School of Informatics

Git is a version control system which has become very popular within Informatics. In fact it has become so popular that we are now offering no less that three different Git related services within the School! At this point, if you are familiar with Git, you may be wondering why we bother since it is trivial for any user to set up a Git repository in their home directory with a couple of simple commands. This is true, and indeed may be all you need if you are the only person using that repository. Setting up a Git repository to be used by others is trickier and it is this need which the School Git services aim to meet.

First up, we have and its close associate, the longest running of the three service and the closest to a “classic” Git service. This supports Git over the git:// and ssh:// protocols. So far, so nothing special but as the second URL suggests, this Git service is run in conjunction with a Gerrit instance. Gerrit is a web based code collaboration tool. Because it is web based, it means that external collaborators can access repositories by creating an iFriend account and, after visiting the gerrit URL (which automatically creates an account for them), register one or more ssh public keys allowing them to contribute to the Gerrit repositorys if they have the necessary permissions. This last condition is necessary because Gerrit provides fine grained control over what access registered users have to a project. Finally, Gerrit provides code review which may be important for some projects. You can find out more about the Git/Gerrit service here.

One issue with Gerrit is that it can be tricking to configure and manage permissions for, and contributions to, a project. In an effort to provide a multi-user Git service which would offer many of the advantages of Gerrit without all the complexities, we have introduced The main feature which makes the git2 service stand out is that the Git repositories are located on AFS file space. When a repository is set up (and another advantage of git2 is that repositories can be set up by users, there is no need to request Computing Support to set up a repository), two AFS groups are set up, one giving read access to the repository and the other write access. The repository owner can therefore control access to the repository by putting users in the appropriate groups. Access is via the file:// protocol (though repositories may also be made readable via the git:// protocol if desired). It will be seen therefore that for a user to be able to access a repository, they must have AFS access. iFriend accounts can be given AFS credentials allowing external collaborators to access repositories though they can do so only through an AFS client. Find out more about this service here.

Finally, we have, a local Gitlab-CE instance and intended as a short term stand in until a mooted college-wide Gitlab service comes along. This is very much a test service at the moment and as such does not feature some aspects which would normally be expected of a DICE service such as integrated sign-in via Cosign. Instead, you must currently create your own account when you first connect to the service and will have to set up a password which is unconnected to any other School or University password (and please don’t reuse an existing password!). Access to the Gitlab Git repositories is currently only available via the http:// protocol. External users can make use of this service but will also need to create an account. As mentioned, this is a test service which will continue to be developed and is subject to withdrawal at very short notice if necessary (for example if there are security concerns). This Gitlab service can be found at

So which Git service should you use? If you absolutely must have code review, then Git/Gerrit is the one to use. If you want a straightforward self-service Git service and all your external collaborators who will need to contribute to the repository have access to an AFS client, then git2 may be a good fit for your needs. And if you would like to try a web based development environment and can live with the possibility that it may disappear at short notice, then why not give Gitlab a try?

Questions and suggestions about how these services might be improved are welcome. Please use the support form to make contact.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply