Brian Mills

Installing Gitolite is very easy, particularly if you are using Git on recent version of Ubuntu (10.10 I think).

Assumptions:

1. You are working on a client pc of some sort
2. You want to install gitolite onto a server which is not the client
3. You already have openssh access from the client to the server using RSA keys

All you need to do is:

1. Install the package (gitolite) on the server
2. Set up Gitolite on the server
3. Configure repositories in the Gitolite admin repository from the client

Installing Gitolite

As it is in the Ubuntu packages, all you need to do is run these commands on the server.

> sudo apt-get update
> sudo apt-get install gitolite

And your done.

Setup Gitolite

You need to have a public key somewhere public accessible (world readable) on the server to setup gitolite.

If you have ssh’d into the server using an RSA key already, copy your public key to the temp directory and make it world readable by running these commands.

> cp ~/.ssh/id_rsa.pub /tmp/[username]-id_rsa.pub
> chmod 666 /tmp/[username]-id_rsa.pub

Then you need to run the gitolite setup referencing your public key. This is so you can admin the server once you have run the setup.

> sudo su gitolite
> gl-setup /tmp/[username]-id_rsa.pub

Gitolite is now setup.

Configure Repositories

Now that you have it setup, on your client pc, you should be able to clone the admin repository to start configuring new repositories.

[sourecode language=shell]
> git clone gitolite@[serverurl]:gitolite-admin gitolite-admin
[/sourcecode]

You now have a local copy of the admin repository, which you make changes to, and then push back to the server. (You could do this on the server itself if you wanted to as well).

The admin repository has 2 directories.

• keydir = contains user public keys in the form [username].pub
  where [username] could be their name or email address or any other identifier you find useful.
• conf/gitolite.conf = is the default config file containing the name’s of repositories, and user access permissions
  this file can be split up if desired.

Config File Options

To define a repository insert a line like this

repo    [repository path and or name]
RW+  =  [username list seperated by spaces]

Note: username is the same as the key file name without the .pub at the end

To define a list of users in an easy list, insert a line like this

@[niceNameForUsers]  =  [useranme list seperated by spaces]

Which can make it a little easier to read who has permissions if you define a shortcut for group of users.

Permissions can be defined as these options

• R = read permission to the repository for the users listed
• RW = read/write permission to the repository for the users listed
• RW+ = read/write/nonfastforwardwrite permissions to the repository for the users listed

The RW+ Non fast forward write means you can push a branch that removes history using the force option.
Standard RW permission does not allow you to remove history already part of an existing branch.

There are plenty of other config options, including exposing repositories over GitWeb if you setup GitWeb, as well as other shortcut options, but that gives you the ability to create repositories and give read, or read/write permissions to the repositories.

I’m in the midst of installing GitHub into our organisation. GitHub has a commercial offering called GitHub:Fi which allows you to install and run a copy of GitHub within your own network behind your firewall. Which is great for a large organisation that wants the GitHub experience, but are unwilling to let their source code outside their network. For a small business however, its not very costly, and probably out of reach.

There are a few other options though.

1. Gitorious is a open source equivalent to GitHub, you can purchase support to install Gitorious and access the developers as consultants to work on new features or integration with existing systems. It seems they are more open to customisations than GitHub.
2. Gitolite is a great little app that allows you to create and manage the hosting of Git repositories through a Git repository. Its simple, fast and very lightweight. It does not have a web interface to manage and view repositories, but it allows for very fine controlled security which can be favorable in a corporate environment. There are quite large installs of Gitolite, so much so that they have a dedicated “big config” flag to change the way it configures itself internally in situations where you have several thousand repositories or users. So its been well tested.
3. Gitosis is an alternative to Gitolite. It has been around longer, but does not have as many features for controlling security(at the time I reviewed them).
4. For small business’s I have been using the fantastic service at Repository Hosting (http://repositoryhosting.com/) which is unbeatable on price, and allows the hosting of git, mercurial or svn repositories and for each repository also runs trac for issue management, and a webdav access for file sharing on a project.

At the moment I’m using Gitolite, and for fun, I’m exploring the use of Gitorious instead (I don’t really need the web administration side, but I like the idea of it).