master TOC | chapter TOC | support | license

WARNING: This is not the latest gitolite; please see the README

other tips

personal branches

Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer. See here for details.

rule accumulation

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

specifying gitweb and daemon access

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: daemon and gitweb.

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:

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 @all (that is, using either repo @all or R = @all), will not work unless you set the rc-file variable $GL_ALL_INCLUDES_SPECIAL to 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 environment.

repo specific git config commands

(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_KEYS in 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 = gitolite-commits@example.tld
    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 (--add, the value_regex, etc) are not supported.


WARNING: simply deleting the config line from the conf/gitolite.conf file 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-all operation 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 (repo @all, or repo patterns like repo foo.*) first, and place more specific ones later to override the generic settings.