6e29365316
I got tired of being told "TL;DR". Now the online versions of most documents fit on a page or two, or at least most of them do. The rest has been split out (and you can see the links to the split out sections right where the text is in the raw Markdown). This is much more pleasant to read, and I've improved the linking so it's much less effort for me to keep the links correct.
117 lines
5.7 KiB
Markdown
117 lines
5.7 KiB
Markdown
# F=gerrit comparing gerrit and gitolite
|
|
|
|
Gerrit and gitolite have too many high level differences. Size is most
|
|
visible of course: 56000 lines of Java versus 1300 lines of perl+shell,
|
|
according to David A. Wheeler's 'SLOCCount' tool. Gerrit needs a database (it
|
|
comes with a perfectly usable one, or I believe you can use any of the usual
|
|
suspects),
|
|
and even comes with its own ssh server and git server, and since the git
|
|
engine is internal it probably has to include a lot of things that normal git
|
|
already has; I wouldn't know for sure.
|
|
|
|
Gerrit allows a lot more de-centralisation in managing the system, and of
|
|
course excels at code review, and it seems geared to really large, open
|
|
source-ish projects with lots of contributors.
|
|
|
|
Gitolite works on a pure command-line install and a plain text file config,
|
|
and is designed to run unobtrusively and quite transparently to all developers
|
|
-- other than sending the admin their pubkey, nothing really changes for them
|
|
in their workflow, toolset, etc. The "lite" in the name still holds, despite
|
|
all the extra features being pumped in!
|
|
|
|
Gitolite was mainly written for a corporate environment, where we really,
|
|
really, need branch-level ACLs. While they would certainly love the code
|
|
review part, things like *voting* on a change, and so on seem a bit alien, and
|
|
it seems to me that code review itself is more likely to be a hierarchical
|
|
thing, not a peer-to-peer, "anyone can comment" thing. I could be wrong.
|
|
|
|
----
|
|
|
|
In short, gitolite doesn't do the main thing that gerrit does, and gerrit is
|
|
so much bigger than gitolite in so many ways, it seems really odd to compare
|
|
them at all.
|
|
|
|
However, it seems gerrit comes closest to gitolite in terms of flexibility of
|
|
access control, which is gitolite's main strength, so I thought it would be
|
|
useful to compare gitolite with just what is in the "access-control.html" in
|
|
the gerrit war file. Or see [this][gdac]. [...and stop sniggering at the
|
|
"svn" in the link dammit!]
|
|
|
|
Note that I don't necessarily list something that both tools have. (For
|
|
example, per-user branches denoted by `/USER/` in gitolite and `$(username)`
|
|
in gerrit, or being able to distinguish between creating a branch and pushing
|
|
to an already created one, etc).
|
|
|
|
[gdac]: http://gerrit.googlecode.com/svn/documentation/2.1.2/access-control.html
|
|
[jwzq]: http://regex.info/blog/2006-09-15/247
|
|
|
|
**Administrators**: anyone who has gitolite-admin push privs
|
|
|
|
**Anonymous Users**: gitolite doesn't do that, though the "ssh-plus" branch,
|
|
combined with git-daemon2 (Ilari) will allow that in future. When git-daemon2
|
|
becomes mainstream, the supporting code in this branch will also be merged
|
|
into "master".
|
|
|
|
**Registered Users**: @all
|
|
|
|
**Account Groups**: @groups in gitolite. We do allow them to be nested,
|
|
although the parsing is single-pass. We also don't have group `foo-admin`
|
|
managing membership to group `foo` though; all groups are managed by the eqvt
|
|
of "Administrators".
|
|
|
|
**Project ACLs**: first, let's remember (again) that we don't have any of the code
|
|
review stuff :)
|
|
|
|
* This is a subjective point, but gerrit doesn't give permissions to
|
|
individual users, only groups. People who have several small projects
|
|
(only one QA, one integrator, etc.), would have to create lots of 1-man
|
|
groups, which could be cumbersome.
|
|
|
|
* **Evaluation** order and priority of access control rules are different.
|
|
Gerrit goes by specificity, gitolite goes by sequence. It shouldn't
|
|
matter; they're probably equivalent except perhaps in some far-fetched
|
|
scenarios.
|
|
|
|
* Update 2010-10-24: as per [this][gitlog1] Gerrit now has *read* access
|
|
control at the branch level -- they can afford to do that because they
|
|
have a full jgit stack to play with. Even then it was not easy -- they
|
|
had to implement a callback from jgit to gerrit for the fetch, *and* deal
|
|
with evil clients that might try to read an object by *pushing* a supposed
|
|
change on top of a SHA that they know but don't actually have. (You'll
|
|
have to think about this carefully; it may not be immediately obvious to
|
|
people who do not know the ref-exchange in the git protocol).
|
|
|
|
Gitolite is dependent on git itself to provide that -- it just cannot be
|
|
done without support from git core. I can see some corporates drooling at
|
|
this possibility (makes no sense for open source projects IMO) ;-)
|
|
|
|
My normal recommendation is to **use separate repos** if you really need
|
|
this while continuing to use gitolite. Much simpler and easier to audit
|
|
and to convince auditors that "those people can't see that code".
|
|
|
|
**Categories**:
|
|
|
|
* gitolite doesnt have an "owner" for each project in any administrative
|
|
sense. Perhaps you could consider whoever has `RW+` perms to be an owner
|
|
but it doesn't go beyond what that implies.
|
|
|
|
* gitolite doesnt do anything special to signed or annotated tags
|
|
|
|
* Force push is the same as delete by default. However, gitolite can now
|
|
allow these two separately if that's how you need it.
|
|
|
|
Of course, direct pushing clashes with code review, and gerrit recommends
|
|
that if you want code review you should not use this feature. [Normal
|
|
pushes in gerrit go through a temp branch that is moved to the correct one
|
|
after a review is done; direct pushes are all that gitolite has].
|
|
|
|
* author/committer identity: checking these fields in pushed commits is
|
|
likely to be important in some projects, but gitolite doesn't have any
|
|
notion of this. Hmm... I smell another feature in the future :)
|
|
|
|
The rest of it is in areas that the two tools have no overlap on (again, code
|
|
review being the main thing), or, as I said at the top, features that both
|
|
tools have.
|
|
|
|
[gitlog1]: http://colabti.org/irclogger/irclogger_log/git?date=2010-09-17#l2710
|