112 lines
5.4 KiB
Markdown
112 lines
5.4 KiB
Markdown
# 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,
|
|
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!]
|
|
|
|
[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 :)
|
|
|
|
* **Reference-level access controls** make no mention of regexes. I'm not
|
|
[JWZ][jwzq], and I strongly consider regexes a plus point :)
|
|
|
|
* They also make no mention of giving permissions to individual users, only
|
|
groups. If this is true, it would be a little cumbersome when managing
|
|
many small projects -- projects where you have only one QA, one
|
|
integrator, etc., would end up making many 1-man groups. [If anyone who's
|
|
used gerrit can correct me on this I'd appreciate it].
|
|
|
|
* **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.
|
|
|
|
* One big difference is that gitolite does not process "deny" rules ("-1 no
|
|
Access" in gerrit terms) for *read* access -- we only support those for
|
|
write access. Gerrit uses this to "hide a handful of projects on an
|
|
otherwise public server"; in gitolite you'd better avoid giving `R = @all`
|
|
in the first place :)
|
|
|
|
* [Update 2010-04-14: it appears that Gerrit is also in the process of
|
|
implementing *read* access control at the branch level -- they can afford
|
|
to even think of that because they have a full jgit stack to play with.
|
|
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) ;-)]
|
|
|
|
**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
|
|
|
|
* gitolite always allows creating a branch. The only way to prevent that is
|
|
to list out allowed branches explicitly (make sure you end the refex with
|
|
a `$`!).
|
|
|
|
* Force push is the same as delete: historically (and by default, even now)
|
|
gitolite does the same . However, I've only recently (and somewhat
|
|
reluctantly) changed gitolite to allow treating these two separately.
|
|
|
|
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).
|