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

1 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.

2 putting 'repositories' and '.gitolite' elsewhere

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

3 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

Run this from cron or however you want.

4 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 (see "roles" in this page).

(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).

5 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:

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:

That's it.