gitolite/doc/special.mkd

# special features and setups

----

[[TOC]]

----

## #elsewhere putting 'repositories' and '.gitolite' somewhere else

Gitolite insists that the "repositories" and ".gitolite" directories be in
`$HOME`.  If you want them somewhere else:

  * do the install as normal,
  * *then* move those directories to wherever you want and replace them with
    symlinks pointing to the new location.

## #writable disabling pushes to take backups

The `writable` command allows you to disable pushes to all repos or just the
named repo, in order to do file-system level things to the repo directory that
require it not to change, like using normal backup software.

Run `gitolite writable -h` for more info.

## #pers "personal" branches

"personal" branches are great for environments where developers need to share
work but can't directly pull from each other (usually due to either a
networking or authentication related reason, both common in corporate setups).

Personal branches exist **in a namespace** of their own.  The syntax is

        RW+ personal/USER/  =   @userlist

where the "personal" can be anything you like (but cannot be empty), and the
"/USER/" part is **necessary (including both slashes)**.

A user "alice" (if she's in the userlist) can then push any branches inside
`personal/alice/`.  Which means she can push `personal/alice/foo` and
`personal/alice/bar`, but NOT `personal/alice`.

(Background: at runtime the "USER" component will be replaced by the name of
the invoking user.  Access is determined by the right hand side, as usual).

Compared to using arbitrary branch names on the same server, this:

  * Reduces namespace pollution by corralling all these ad hoc branches into
    the "personal/" namespace.
  * Reduces branch name collision by giving each developer her own
    sub-hierarchy within that.
  * Removes the need to think about access control, because a user can push
    only to his own sub-hierarchy.

## delegating access control responsibilities

See [this][deleg].

## #keysonly using pubkeys obtained from elsewhere

If you're not managing keys via the gitolite-admin repo, but getting them from
somewhere else, you'll want to periodically "update" the keys.

To do that, first edit your rc file and add something like this:

    SSH_AUTHKEYS                =>
        [
            'post-compile/ssh-authkeys',
        ],

Then write a script that

  * gets all the keys and dumps them into `$HOME/.gitolite/keydir` (or into a
    subdirectory of it).

  * runs `gitolite trigger SSH_AUTHKEYS`.

Run this from cron or however you want.

## #gh giving users their own repos

(Please see [this][wild] for background on the ideas in this section).

It's very easy to give users their own set of repos to create, with the
username at the top level.  The simplest setup is:

    repo CREATOR/..*
        C   =   @all
        RW+ =   CREATOR
        RW  =   WRITERS
        R   =   READERS

Now users can create any repo under their own name simply by cloning it or
pushing to it, then use the [perms][] command to add other users to their
WRITERS and READERS lists.

Of course you can get much more creative if you add a few more roles (see
"roles" in [this][wild] page).

<font color="gray">(I prefer using some prefix, say "u", as in `repo
u/CREATOR/..*`.  This helps to keep user-created repos separate, and avoid
name clashes in some far-fetched scenarios).</font>