gitolite/doc/2-admin.mkd

# administering and running gitolite

*Note*: some of the paths in this document use variable names.  Just refer to
`~/.gitolite.rc` for the correct values for *your* installation.

In this document:

  * administer
      * adding users and repos
      * specifying gitweb and daemon access
      * custom hooks

### administer

First of all, ***do NOT add new repos manually***, unless you know how to add
the required hook as well.  Without the hook, branch-level access control will
not work for that repo, which sorta defeats the idea of using gitolite :-)

Please read on to see how to do this correctly.

#### adding users and repos

  * ask each user who will get access to send you a public key.  See other
    sources (for example [here][genpub]) for how to do this

[genpub]: http://sitaramc.github.com/0-installing/2-access-gitolite.html#generating_a_public_key

  * rename each public key according to the user's name, with a `.pub`
    extension, like `sitaram.pub` or `john-smith.pub`.  You can also use
    periods and underscores

  * copy all these `*.pub` files to `keydir` in your gitolite-admin repo clone

  * edit the config file (`conf/gitolite.conf` in your admin repo clone).  See
    `conf/example.conf` in the gitolite source for details on what goes in
    that file, syntax, etc.  Just add new repos as needed, and add new users
    and give them permissions as required.  The users names should be exactly
    the same as their keyfile names, but without the `.pub` extension

  * when done, commit your changes and push

#### specifying gitweb and daemon access

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.

To make a repo or repo group accessible via "git daemon", just give read
permission to the special user "daemon".  See the [faq, tips, etc][ss]
document for easy ways to specify access for multiple repositories.

[ss]: http://github.com/sitaramc/gitolite/blob/pu/doc/3-faq-tips-etc.mkd#gwd

There's a special user called "gitweb" also, which works the same way.
However, setting a description for the project also enables gitweb permissions
so you may as well use that method and kill two birds with one stone, like so:

    gitolite = "fast, secure, access control for git in a corporate environment"

Note that gitolite does **not** install or configure gitweb/daemon -- that is
a one-time setup you must do separately.  All this does is:

  * for daemon, create the file `git-daemon-export-ok` in the repository
  * for gitweb, add the repo to the list of projects to be served by gitweb
    (see the config file variable `$PROJECTS_LIST`, which should have the same
    value you specified for `$projects_list` when setting up gitweb)
  * put the description, if given, in `$repo/description`

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.

#### custom hooks

If you want to put in your own, custom, hooks every time a new repo is created
by gitolite, put a **tested** hook script in `src/hooks`.  As distributed, the
only file there is the `update` hook, but everything (*everything*) in that
directory will get copied to the `hooks/` subdirectory of every *new* repo
created.

In order to push a new or updated hook script to *existing* repos as well,
just run easy install once again; it'll do it to existing repos also.

**VERY IMPORTANT SECURITY NOTE:  the `update` hook in `src/hooks` is what
implements all the branch-level permissions in gitolite.  If you fiddle with
the hooks directory, please make sure you do not mess with this file
accidentally, or all your fancy per-branch permissions will stop working.**