www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sitaram Chamarty <sitar...@gmail.com>
Subject Re: Gerrit over gitolite? was: Git Tasks
Date Mon, 29 Nov 2010 04:56:36 GMT
Gerrit does a few things (notably anything to do with the actual
workflow of accepting patches) which gitolite does not do, and will
not do.  As such, I would tend to agree with Thomas about using Gerrit
if you need those features.

However, just for the sake of completeness, and even if you don't use
gitolite for any reason, I thought I'd briefly describe how gitolite
would do these things.

on 11/29/2010 03:21 AM Thomas Koch wrote:
> Paul Querna:

>> Task: pre-receive hook: Authorization. Based on groups in LDAP,
>> restrict write access to members of the correct project. We will
>> not have path based authorization under, only whole project.
> LDAP based authorization is a standard feature of Gerrit.

With gitolite it requires one external script, whose function can be
described as "given a username, return a list of groups to which the
user belongs".

Note that's about authorisation.  Authentication is completely outside
gitolite (either sshd or apache will do that and pass on an
authenticated username as arg-1 to gitolite's entry point script).
Thus apache itself may use LDAP for authentication in the normal way.

>> Task: pre-receive hook: Do not allow history rewriting / git push
>> --force.
> Just don't give anybody this access right in Gerrit. Gerrit's
> provides three levels of push branch rights: Update Branch, Create
> Branch, Force Push Branch & Delete Branch

Ditto, except gitolite can separate force push from delete also.

>> Task: post-update hook: Logging of commit. Log both the Apache
>> committer, and the 'git' committer. Figure out how to make this
>> information useful.
> Standard Feature of Gerrit.

The apache committer is logged by gitolite, along with the old SHA,
the new SHA, etc.  The git committer of the topmost commit is in the
new SHA.

I say "topmost commit" because a single push can and often does send
multiple commits (in a chain).  Which could each have different
committers.  So you probably need to define "git committer" more
precisely here.

>> Task: post-receive hook: E-Mail notification. We have a
>> traditional dependence on 'good' commit emails. We need a very
>> good mailer, as SvnMailer handles many cases like large commits,
>> weird charactersets, etc, that most git based mailers don't even
>> approach.
> Users in gerrit can subscribe for each project on New Changes, All
> Comments and Submitted Changes. Notifications can also be selected
> only for specific branches of a project.

Gerrit++ on this.  Gitolite leaves it all to you.  KDE has implemented
a "watch" script and command to deal with this, and it's not too hard,
but having it built in is nice.

>> Task: post-receive hook: CIA Notification. <http://cia.vc/>
> Don't know.

Ditto :)

>> Task: post-receive hook: SvnPubSub Notification. I think we
>> should add support to SvnPubSub for git repositories. Maybe rename
>> SvnPubSub -> VcPubSub too.
> Don't know.


>> Task: post-receive hook: Slave Mirroring. Every commit will be
>> mirrored to a second ASF machine, just like we do with Subversion.
>> This should just be a git push --mirror to a remote repository, but
>> it needs testing.
> Replication is a standard feature of Gerrit to provide a hot fail
> over master server or mirrors for load balancing. I don't know,
> whether master-master replication is possible with Gerrit.

Gitolite can do mirroring -- basically a hot standby.

Master-master replication is, IMO, not possible in *any* sane VCS.

>> Task: post-receive hook: Github mirroring. After each push, every
>> repository will be mirrored to github.
> Ok, trivial hook, not in Gerrit.

The mirroring I talk of in the previous point also involves a "list of
slaves" configuration variable.  Just add the github URL to this

>> Task: Find web based view of Git repositories. Gitweb or cgit or
>> viewvc. Evaluate and configure one of them.
> Web-Git integration build in in Gerrit.

Gerrit++ on this also.  Although, I have to say lots of gitolite users
use gitweb and cgit quite happily.

> It really seems obvious to me, that Gerrit would save a lot of work
> compared with a home grown solution. Also the creation of Git
> repositories can be managed via gerrit.

KDE has gone much further along this line (creation of git repos) than
I anticipated, using gitolite's "wildcard repo" feature (where the
admin specifies a pattern and allows user to create their own repos)
and various commands to control such repos.  Sections 4 and 5 of
http://community.kde.org/Sysadmin/GitKdeOrgManual explain in more
detail.  Note that even if you're using http (git's smart-http mode,
as described in "man git-http-backend") instead of ssh, you can still
do all this, except with a somewhat different syntax.



View raw message