How many times have you been in this situation: You recognize the need to use version control in your organization, or at least on your projects. Your organization does not. Your sysadmins are unresponsive to requests to support new things regardless the lack of any kind of VCS. Nonetheless, you refuse to not use VC on your projects.

Have you never been in that situation? Weird. You're lucky.

Gitolite is a utility for serving up repositories and controlling which users are able to read, write, force-update, delete, or create repositories. Useful when coordinating a project between different people or from different machines.

The normal install instructions for Gitolite require a special user account, and as we've established, your organization might be unreceptive to doing things. Here I'll show you how to (somewhat sanely) host Gitolite in your own user account without bothering admins.

Install gitolite

You can leave the executable in a directory in your home directory.

git clone git://github.com/sitaramc/gitolite ~/gitolite

We'll be following "option 1" with reference to the Gitolite docs.

cd gitolite
./install

SSH keys

Gitolite authenticates using SSH.

To keep Gitolite usage segregated from your normal account usage, create a new keypair for Gitolite operations.

cd ~/.ssh
dekkera:.ssh peter$ ssh-keygen -t rsa -f git_id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in git_id_rsa.
Your public key has been saved in git_id_rsa.pub.

Store a copy of the git_id_rsa.pub in the gitolite folder, as 'your_name.pub', and tell Gitolite to set up using that key. Reference Gitolite docs: setup and note we are using the "host alias" option.

cp git_id_rsa.pub ~/gitolite/your_name.pub
cd ~/gitolite
gitolite -setup -pk your_name.pub

It's worth stating what "setup" did.

First, it populated "~/repositories" with the default admin respository and the testing repository, and put you authorized key in the admin repository.

Then it checked out the admin repository to ~/.gitolite

Finally it added some lines to your .ssh/authorized_keys file, like this:

# gitolite start
command="/Users/peter/gitolite/src/gitolite-shell your_name",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3Nza<rest of key>== your_name@your_host
# gitolite end

These lines mean that an SSH connnection made using this public key will connect to the Gitolite shell. (When you add other users, this means you are giving permission for them to run Gitolite under your UID. This is why the usual practice is to have a separate UID for Gitolite, in case Gitolite has an exploit.)

Test it out now:

your_host:gitolite your_name$ ssh -x -i ~/.ssh/git_id_rsa your_name@your_host info
hello yourname, this is your_name@your_host running gitolite3 v3.04-13-gcc9727c on git 1.9.1

 R W    gitolite-admin
 R W    testing

Important things to note: gitolite is running under your uid (are you OK with that?), and there are two repos to start with that you can read and write to.

For convenience, you can also create a host alias, by adding these lines to .ssh/config:

Host home
User your_name
Hostname your_host
IdentityFile ~/.ssh/git_id_rsa

This means you can clone things from home/repo rather than your_name@your_host/repo (and if your gitolite host moves you can track it by updating your SSH config instead of updating all the remotes in your checked out repositories).

Tell Git to use its own key

To facilitate interaction with Gitolite from your own account, make Git use this key. (Other users can use their keys ordinarily.) Make a script gitssh cat > ~/bin/gitssh #!/bin/sh exec ssh -x -i ~/.ssh/git_id_rsa $@

Make it executable and this line to your .bashrc:

export GIT_SSH=$HOME/bin/gitssh

Adding new users and repositories

Administrate gitolite by cloning the admin respotitory.

dekkera:gitolite peter$ git clone your_name@your_host:gitolite-admin
#can also "git clone home:gitolite-admin" with a host alias

(If this doesn't work, make sure you configured gitssh and check the environment variable GIT_SSH as discussed above.) Note that if you set up a host alias you can clone from home:gitolite-admin

To add a user, go into keydir and add their SSH public key as their_name.pub.

To add repositories and control access permissions, edit conf/gitolite.conf. and either add new lines for a new reporter.

See the docs. Go ahead and add these lines:

repo CREATOR/..*
    C = @all
    RW+D = CREATOR
    R = @all

This allows users to add and delete their own repositories stored under their own subdirectory.

Here, "R" allows reading, "W" allows writing, and "+" allows forced updating. "C" allows creation and "D" deletion of repositories.

Commit your changes and do a git push and gitolite will receive the new setting.

your-host:gitolite-admin your_name$ git add -A
your-host:gitolite-admin your_name$ git push origin master
Everything up-to-date
your-host:gitolite-admin your_name$ git commit -m 'adding self-created repo rule'
[master c53a070] adding self-created repo rule
 1 file changed, 6 insertions(+), 1 deletion(-)
your-host:gitolite-admin your_name$ git push origin master
Counting objects: 10, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 402 bytes | 0 bytes/s, done.
Total 4 (delta 1), reused 0 (delta 0)
To home:gitolite-admin
   0b61e82..c53a070  master -> master

If you added a repo to gitolite.conf you will see a message about initializing a new repo.

Checking out on other machines

On another machine, make sure you have set up your host alias and a SSH keypair that gitolite recognizes, then do

git clone home:your_repo

Note that a user other_name clones by running, effectively, git clone your_name@your_host:repo, because the repos live in your account. So they are using SSH to connect to your account, and your ~/.ssh/config directs them to use gitolite as a login shell.

Getting help

Gitolite can communicate help and usage messages. Try the following:

ssh home help
ssh home info
ssh home desc -h

Remotely creating repositories

The lines we added with CREATOR allows users to remotely create and delete repositories. See docs under wild repositories.

Try it out:

your-host:gitolite-admin your_name$ git clone home:your_name/new_repo
Cloning into 'new_repo'...
Initialized empty Git repository in /Users/your_name/repositories/your_name/new_repo.git/
warning: You appear to have cloned an empty repository.
Checking connectivity... done.

You can also take an existing repository, set its remote to home/your_name/new_repo, and push it on up.

Remotely deleting repositories

Remotely deleting a repo requires enabling the delete command. To enable "D", uncomment the relevant line in ~/.gitolite.rc.

Then you can delete repositories where you have the "D" permission:

your-host:~ your_name$ ssh home D unlock your_name/new_repo
'your_name/new_repo' is now unlocked
your-host:~ your_name$ ssh home D rm your_name/new_repo
'your_name/new_repo' is now gone!

Controlling access to branches

Gitolite can also control access to read and write on a per-branch level.

A useful configuration is to only allow non-forced updates for top-level branches, but allow contributors to do whatever they want (create, delete, force-update) with their own branches. This lets the repo owner control the top level, but contributors make their own branches and pull requests.

TODO show how this is done.

Mirroring github

would like to automatically make a local mirror of my Github stuff; with triggers on pull and push