98 lines
3.3 KiB
Markdown
98 lines
3.3 KiB
Markdown
# 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.
|