master TOC | chapter TOC | support | license
WARNING: This is not the latest gitolite; please see the README
Gitolite has an advanced access control language that is designed to be powerful but easy to use. Other objectives were that it should be even easier to read, review and audit the rules, and it should scale to thousands of repos and users. There was also, in the author's mind, a desperate need to create something as different as possible from the brain-dead, nausea-inducing "Windows INI" style syntax that some other popular tools seem to favour.
This is a quick recap of the most common elements in a typical config file. (In the following description, the angle brackets are not part of the syntax).
(optional) group definitions
@<groupname> = <list of users and groups>
repo access rules
repo <reponame> # one or more access rules like <permission> <optional refex> = <list of users and groups>
The most common permissions are:
-(the minus sign), to deny access
If no refex is supplied, the access rule applies to all refs.
Later, gitolite acquired
Even later, gitolite acquired, if you want to enforce a rebase-only workflow.
gitolite.conffile. If narrative descriptions scare you, or your English is not upto scratch, try gitolite config by example also.
The full set of permissions, in regex syntax:
-|R|RW+?C?D?M?. This expands
to one of
RW+CD, all but the first one optionally followed by an
M. And by now you
know what they all mean.
[Side note: There is one more very important permission to be dealt with --
C, which is not really a "ref" level permission and can be
found in doc/wildcard-repositories.mkd.]