diff --git a/contrib/gerrit.mkd b/contrib/gerrit.mkd new file mode 100644 index 0000000..f08a1af --- /dev/null +++ b/contrib/gerrit.mkd @@ -0,0 +1,111 @@ +# 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).