master TOC | chapter TOC | support | license
WARNING: This is not the latest gitolite; please see the README
Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer. See here for details.
(Also see this for a different example that may be more intuitive for some people).
Gitolite lets you specify access rules for a repo in bits and pieces, and accumulates them in the same sequence they were given. This is very convenient. Let's say you have a mix of open source and closed source projects, and "bosses" should have read access to all projects, and everyone should have read access to open source projects. Assuming the appropriate group definitions, this would work:
# all bosses have read access to all projects repo @open @closed @topsecret R = @bosses # everyone has read access to "open" projects repo @open R = @bosses @devs @interns
If you notice that
@bosses are given read access to
@open via both rules,
don't worry that this causes some duplication or inefficiency. It doesn't :-)
Elsewhere in the file, you would specify access for individual repos (like RW, RW+, etc). Gitolite combines all of these access rules, maintaining the textual order in which they occur, when authorising a push.
And although this example used groups, you can use reponames as well, or mix and match them. You can even distribute rulesets across multiple "include" files if you wish.
Just remember that if you use deny rules anywhere then the order of the rules matters!
This feature also helps people who generate their gitolite.conf itself from some other database -- it allows them much more flexibility in how they generate rules.
Gitolite allows you to specify access for git-daemon and gitweb. This is a feature that I personally do not use (corporate environments don't like unauthenticated access of any kind to any repo!), but someone wanted it, so here goes.
Gitolite has two pre-defined, "special", usernames:
To make a repo or repo group accessible via "git daemon", just give read
permission to the special user "daemon". Similarly, give read permission to
gitweb to allow the gitweb CGI to show the repo. Something like this:
repo foo bar baz R = gitweb daemon
This gives you a quick way to offer multiple repos up for gitweb and/or daemon access.
However, setting a description for the project also enables gitweb permissions so you can do it that way if you want. Of course in this case you have to deal with each repo separately. Add lines like this to gitolite.conf:
foo = "some description" bar = "some other description" baz = "yet another description"
You can also specify an owner for gitweb to show, if you like; for example I might use:
gitolite "Sitaram Chamarty" = "fast, secure, fine-grained, access control for git"
These lines are standalone, so you can add them anywhere in the conf file.
Note that gitolite does not install or configure gitweb/git-daemon -- that is a one-time setup you must do separately. All gitolite does is:
git-daemon-export-okin the repository
$PROJECTS_LIST, which should have the same value you specified for
$projects_listwhen setting up gitweb)
The "compile" script will keep these files consistent with the config settings -- this includes removing such settings/files if you remove "read" permissions for the special usernames or remove the description line.
Please note that giving permissions to these special users via
(that is, using either
repo @all or
R = @all), will not work unless you
set the rc-file variable
1. Also, NOTE
that giving them read access to
repo @all means the
gitolite-admin repo is
also accessible. It is upto you to decide if that is OK in your
(Thanks to teemu dot matilainen at iki dot fi)
Note: this won't work unless the rc file has the right settings; please see
$GL_GITCONFIG_KEYSin the rc file doc for details and security information.
Sometimes you want to specify
git config settings for your repos.
For example, say you have a custom post-receive hook that sends an email when a push happens, and this hook looks in the config for whom to send the email to, etc.
You can set these git config values within a "repo" paragraph:
repo gitolite config hooks.mailinglist = firstname.lastname@example.org config hooks.emailprefix = "[gitolite] " config foo.bar = "" config foo.baz =
The syntax is simple:
config sectionname.keyname = [optional value_string]
This does either a plain "git config section.key value" (for the first 3
examples above) or "git config --unset-all section.key" (for the last
example). Other forms of the
git config command (
value_regex, etc) are not supported.
WARNING: simply deleting the config line from the
conf/gitolite.conffile will not delete the variable from
repo.git/config. The syntax in the last example is the only way to make gitolite execute a
--unset-alloperation on the given key.
You can repeat the 'config' line as many times as you like, and the last occurrence will be the one in effect. This allows you to override settings just for one project, as in this example:
repo @all config gitolite.mirror.master = "frodo" config gitolite.mirror.slaves = "sam gollum" repo top-secret-project # only sam, because we don't trust gollum config gitolite.mirror.slaves = "sam"
The "delete config variable" syntax can also be used, if you wish:
repo highlander # there can be only one! config gitolite.mirror.master = config gitolite.mirror.slaves =
As you can see, the general idea is to place the most generic ones (
@all, or repo patterns like
repo foo.*) first, and place more specific ones
later to override the generic settings.