gitolite/doc/why.mkd

# why might you need gitolite

[[TOC]]

----

## basic use case

Gitolite is useful in any server that is going to host multiple git
repositories, each with many developers, where "anyone can do anything to any
repo" is not a good idea.  Here're two examples to illustrate.

Example 1, 3 repos, 3 developers with different levels of access to each repo:

    repo foo
        RW+     =   alice
        R       =   bob

    repo bar
        RW+     =   bob
        R       =   alice

    repo baz
        RW+     =   carol
        R       =   alice bob

Example 2, one repo, but different levels of access to different branches and
tags for different developers:

    repo foo
        RW+ master                  =   alice
        RW+ dev/                    =   bob
        RW  refs/heads/tags/v[0-9]  =   ashok

## #alt alternatives

### unix permissions and ACLs

If you're a masochist, you could probably do example 1 with Unix permissions
and facls.  But you can't do example 2 -- git is not designed to allow that!

Here are some other disadvantages of the Unix ACL method:

  * Every user needs a userid and password on the server.
  * Changing access rights involves complex `usermod -G ...` mumblings
    (I.e., the "pain" mentioned above is not a one-time pain!)
  * *Viewing* the current set of permissions requires running multiple
    commands to list directories and their permissions/ownerships, users and
    their group memberships, and then correlating all these manually.
  * Auditing historical permissions or permission changes is impossible.

### #gcr Gerrit Code Review

The best real alternative to gitolite is Gerrit Code Review.  If code review
is an essential part of your workflow, you should use Gerrit.

Here're some high level differences between gitolite and Gerrit:

**Size**: 3000+ lines of perl versus of 56,000+ lines of Java

**Architecture**: Gitolite sits on top of "standard" git and openssh, which
are assumed to already be installed.  Gerrit includes its own git stack (jgit)
and sshd (Apache Mina).  In Java tradition, they all come bundled together.

(Corollary: As far as I know jgit does not support the same hooks that 'man
githooks' talks about).

Gitolite uses a plain text config file; gerrit uses a database.

**User view**: Gitolite is invisible to users except when access is denied.  I
think Gerrit is much more visible to devs.

On a related note, gitolite does not do anything special with signed or
annotated tags, nor does it check author/committer identity.  However, it is
trivial to add your own code to do either (or if someone contributes it, to
just "enable" what ships with gitolite in a disabled state).

### gitorious

Anecdotally, gitorious is very hard to install.  Comparison with gitolite may
be useless because I believe it doesn't have branch/tag level access control.
However, I can't confirm or deny this because I can't find any documentation
on the website.

In addition, the main website hides the source code very well, so you already
have a challenge!  [The only link I could find was tucked away at the bottom
of the About page, in the License section].

### gitlab

Gitlab is built on top of gitolite, but I don't know more than that as yet.
Patches welcome.

### others

Please send in patches to this doc if you know of other open source git
hosting solutions that do access control.