Rietveld is a generic code review tool run on the Google App Engine service. It easily accepts diff output from Git, Subversion, and Mercurial.

Gitosis aims to make hosting git repos easier and safer. It manages multiple repositories under one user account, using SSH keys to identify users. End users do not need shell accounts on the server, they will talk to one shared account that will not let them run arbitrary commands.

Gerrit is a web based code review system, facilitating online code reviews for projects using the Git version control system. Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer. Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer. This functionality enables a more centralized usage of Git.

For some background info on Gerrit (and some details of Rietveld and Gitosis in addition):

http://code.google.com/p/gerrit/wiki/Background

In Gerrit each git repository is managed as a project, so the terms repository and project are used interchangeably below.

Gerrit Pros:

        General:

• Combines two tools: Code Review and Repository Management
• Multiple authentication methods available

• OpenID would be best for an external instance
• LDAP is very nice for internal instances (Good group integration and pre-population of user info from ldap)

• In-house experience with these tools

• Google, Qualcomm, and many others use Gerrit and love it (and contribute to it!)

• Allows partners, chromium.org and internal Google to all use the same tools for Chromium OS

        Repository Management:

• Extensive access control system that is continually improving

• Read permission on a project (repository) can be narrowed down to a single branch
• Can easily have different groups allowed to Approve (LGTM) and Submit (Commit)
• Access controls can be applied to any refspec (specific branch(es), etc)
• You can completely hide a project from everyone and only show it to a specific group(s)

• This could be very useful for hosting the private vendor repositories

• Built-in support for Contribution Agreements
• Gerrit Hooks

• Gerrit does not support traditional git hooks, but does have hooks to trigger actions when you:

• create a new patchset (includes the first time you create a change and subsequent revisions of that change)
• add comments to a change (including any approval or verification information)
• merge or abandon a change

• "Preflight" supported via the Verified bit

• Particularly important in the new system when wanting to rev a package version
• Preflight is a Continuous Integration model that tests each change before merging it into the repository

• This prevents you from ever having a broken tip

• Specific approvers for each project
• LGTM from a project approver enforced before submit
• Allows git replication as an authenticated push between two repositories on a per-ref basis

• Eases use of separate internal and external repositories.

• Various allowable merge policies (including FF-only)
• Possible to use first only as a gitosis replacement (to ease transition)

        User Experience:

• Project watchlists that don't require making changes to a committed file
• Easy to use 'Submit' button (greatly simplifies the process to get non-committer contributed changes committed)
• No ugly ssh-key management. SSH keys are managed by the users, users and groups are managed by admins.

• The ssh key database itself is more robust than the database gitosis uses

• Gitosis falls over at about 500+ ssh keys in the key file because openssh has to do a linear search during each login

• Extensive diff options when reviewing patch sets
• Can upload new patch sets to changes owned by other users

• Far superior to the hacky Rietveld solution of uploading your change in a new codereview issue and telling the other user to close theirs.

• Very clear which project/branch the change you're reviewing is for

Gerrit Cons:

• Switching to Gerrit would require changes to git-cl (or the use of repo) and changes to the overall developer workflow
• Currently doesn't support CC'ing a mailing list (there are some workarounds)
• No Subversion support
• Gerrit doesn't accept email as an input. All reviews must be done on the web.

• Gerrit does allow the use of ssh to approve changes and make overall comments (but not inline comments)

• No support for traditional git hooks, although Gerrit has some built-in hooks of its own (see above)
• Requires dedicated hardware for Code Review (though depending on what hardware gitosis is running on, that may be sufficient for Gerrit)