gitolite/doc/rc.mkd

# the "rc" file (`$HOME/.gitolite.rc`)

**NOTE**: if you're migrating from g2, there are some settings that MUST be
dealt with **before** running `gitolite setup`; please read the [g2
migration][g2migr] page and linked pages, and especially the one on
[presetting the rc file][rc-preset].

----

The rc file for g3 is *quite* different from that of g2.

As before, it is designed to be the only thing unique to your site for most
setups.  What is new is that it is easy to extend it when new needs come up,
without having to touch core gitolite.

The rc file is perl code, but you do NOT need to know perl to edit it.  Just
mind the commas, use single quotes unless you know what you're doing, and make
sure the brackets and braces stay matched up!

Please look at the `~/.gitolite.rc` file that gets installed when you setup
gitolite.  As you can see there are 3 types of variables in it:

  * simple variables (like `UMASK`)
  * lists (like `POST_COMPILE`, `POST_CREATE`)
  * hashes (like `ROLES`, `COMMANDS`)

While some of the variables are documented in this file, many of them are not.
Their purposes are to be found in each of their individual documentation files
around; start with [customising gitolite][cust].  If a setting is used by an
external command then running that command with '-h' may give you additional
information.

## specific variables

  * `$UMASK`, octal, default `0077`

    The default UMASK that gitolite uses makes all the repos and their
    contents have `rwx------` permissions.  People who want to run gitweb
    realise that this will not do.

    The correct way to deal with this is to give this variable a value like
    `0027` (note the syntax: the leading 0 is required), and then make the
    user running the webserver (apache, www-data, whatever) a member of the
    'git' group.

    If you've already installed gitolite then existing files will have to be
    fixed up manually (for a umask or 0027, that would be `chmod -R g+rX`).
    This is because umask only affects permissions on newly created files, not
    existing ones.

  * `$GIT_CONFIG_KEYS`, string, default empty

    This setting allows the repo admin to define acceptable gitconfig keys.

    Gitolite allows you to set git config values using the "config" keyword;
    see [here][git-config] for details and syntax.

    However, if you are in an installation where the repo admin does not (and
    should not) have shell access to the server, then allowing him to set
    arbitrary repo config options *may* be a security risk -- some config
    settings allow executing arbitrary commands!

    You have 3 choices.  By default `$GIT_CONFIG_KEYS` is left empty, which
    completely disables this feature (meaning you cannot set git configs via
    the repo config).

    The second choice is to give it a space separated list of settings you
    consider safe.  (These are actually treated as a set of [regular
    expression][regex] patterns, and any one of them must match).

    For example:

        $GIT_CONFIG_KEYS = 'core\.logAllRefUpdates core\..*compression';

    Each pattern should match the *whole* key (in other words, there
    is an implicit `^` at the start of each pattern, and a `$` at the
    end).

    The third choice (which you may have guessed already if you're familiar
    with regular expressions) is to allow anything and everything:
    `$GIT_CONFIG_KEYS = '.*';`