miscellaneous features

This page has a bunch of features that didn't seem to fit anywhere.

disabling pushes to take backups

The writable command allows you to disable pushes to all repos or just the named repo, in order to do file-system level things to the repo directory that require it not to change, like using normal backup software.

Run gitolite writable -h for more info.

putting 'repositories' and '.gitolite' elsewhere

Gitolite insists that the "repositories" and ".gitolite" directories be in $HOME. If you want them somewhere else:

  • do the install as normal,
  • then move those directories to wherever you want and replace them with symlinks pointing to the new location.

using pubkeys obtained from elsewhere

If you're not managing keys via the gitolite-admin repo, but getting them from somewhere else, you'll want to periodically "update" the keys.

To do that, first edit your rc file and add something like this:

SSH_AUTHKEYS                =>
    [
        'post-compile/ssh-authkeys',
    ],

Then write a script that

  • gets all the keys and dumps them into $HOME/.gitolite/keydir (or into a subdirectory of it), and
  • runs gitolite trigger SSH_AUTHKEYS.

Run this from cron or however you want.

giving users their own repos

(Please see this for background on the ideas in this section).

It's very easy to give users their own set of repos to create, with the username at the top level. The simplest setup is:

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

Now users can create any repo under their own name simply by cloning it or pushing to it, then use the perms command to add other users to their WRITERS and READERS lists.

Of course you can get much more creative if you add a few more roles.

(I prefer using some prefix, say "u", as in repo u/CREATOR/..*. This helps to keep user-created repos separate, and avoid name clashes in some far-fetched scenarios).

administering gitolite directly on the server

The main use of managing gitolite via the admin repo is that you get to version control the access rules. But for large sites, there's another use: you can share the admin load with more people, without having to give all of them shell access on the server.

However, people who use puppet and similar systems already have a conf versioning and management system. And they'd like to continue to use that to manage gitolite repos and users, rather than be forced to do it through the gitolite-admin repo.

Such sites don't really need the admin repo at all, so here's how to get rid of it and run things directly on the server (which you can script into your puppet or similar software quite easily).

First the one-time stuff:

  • install the software as normal

  • run gitolite setup -a dummy instead of the normal setup command

  • delete (or move away) ~/repositories/gitolite-admin.git

  • edit ~/.gitolite/conf/gitolite.conf and remove the gitolite-admin repo and its access line.

  • mkdir ~/.gitolite/keydir (because "setup -a" does not create it, but you will need it later to add keys).

  • run gitolite compile; gitolite trigger POST_COMPILE

To manage gitolite, you can directly edit files in ~/.gitolite (or cause puppet to place files there), and then run the commands in the last step above. For example:

  • copy someone's pubkey file to ~/.gitolite/keydir
  • edit ~/.gitolite/conf/gitolite.conf and add a repo or three, giving access to some user(s)
  • run gitolite compile; gitolite trigger POST_COMPILE

That's it.