master TOC | main page | single-page | license
This is for gitolite "g3"; for older (v2.x) documentation click here
Gitolite insists that the "repositories" and ".gitolite" directories be in
$HOME. If you want them somewhere else:
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.
gitolite writable -h for more info.
"personal" branches are great for environments where developers need to share work but can't directly pull from each other (usually due to either a networking or authentication related reason, both common in corporate setups).
Personal branches exist in a namespace of their own. The syntax is
RW+ personal/USER/ = @userlist
where the "personal" can be anything you like (but cannot be empty), and the "/USER/" part is necessary (including both slashes).
A user "alice" (if she's in the userlist) can then push any branches inside
personal/alice/. Which means she can push
personal/alice/bar, but NOT
(Background: at runtime the "USER" component will be replaced by the name of the invoking user. Access is determined by the right hand side, as usual).
Compared to using arbitrary branch names on the same server, this:
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).
gitolite trigger SSH_AUTHKEYS.
Run this from cron or however you want.
(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).