User: Password:
Subscribe / Log in / New account

Gerrit: Google-style code review meets git

Gerrit: Google-style code review meets git

Posted Nov 9, 2009 15:10 UTC (Mon) by spearce (guest, #61702)
In reply to: Gerrit: Google-style code review meets git by njwhite
Parent article: Gerrit: Google-style code review meets git

The centralized focus has occurred precisely because of the corporate
framework that exists around the original user group. Google built Gerrit
Code Review because we needed a way for engineers to get their code peer-
reviewed, and then submit it to a central repository that everyone else on
the team can go to obtain the reviewed trunk of the project from.

The biggest problem with any DVCS is "where is the trunk of this project".
When the project involves only 3 or 4 people, its easy for everyone to
declare that one user has the trunk on some machine, and that user just
pulls from the other contributors as necessary. When a project involves
30+ people working full-time for a company, often the company doesn't want
to pay a developer to sit there and pull from each person every day. Enter
the concept of a central repository that everyone gets read/write access
to. Its been that way since CVS/SVN/ClearCase, and will be that way far
into the future.

In my past I've also written an email-hook based review system around Git,
for a prior employer. It worked well-enough as you stated, but after using
something like Mondrian/Rietveld/Gerrit Code Review, I'm not sure I'd want
to go back. Editing comments and reading code in a syntax colored side-by-
side viewer is much easier than doing it in an email client against a
unified format patch. Especially when the change is large, such as 500+
lines and spanning 10 files.

Its quite unfortunate that Gerrit only works in the centralized approach
right now. I consider it to be a major design mistake. We cut some
corners early on and didn't make Gerrit properly support the DVCS model its
built on top of it. We are trying to fix those now, but its going to take
a while as its not our major focus. The plan is to:

- Make Gerrit easier to install.

If installation within your own user account can be reduced to
`sudo apt-get install openjdk-6-jre && wget gerrit.jar` then it
becomes more likely you might install it for your own use, even
if the upstream project doesn't use it. If the data store is a
local file in your home directory, with no database server needed,
its possible for the average user to run when they need to.

- Make Gerrit run on top of a distributed database.

My intern this past summer started a distributed database project on
top of git, called "gimd". In theory, if the comments are stored in
files in a git repository, you can share them through the same means
that you share the code itself. This should support a distributed
peer-review network.

- Add email interfaces to Gerrit.

Some people are just die-hard email fans. We should be able to
send them a unified patch by email from within Gerrit, but also
receive their reply and merge their patch comments back into the
side-by-side view of the Gerrit user. Just because you have to
work with a die-hard email user doesn't mean you should also have
to lose the features Gerrit offers.

(Log in to post comments)

Gerrit: Google-style code review meets git

Posted Nov 19, 2009 23:03 UTC (Thu) by khilman (subscriber, #37671) [Link]

Curious if there are any efforts underway for email interfaces?

I see this as the primary obstacle to switching to Gerrit for existing projects that are using email review. Migration of an existing project would require some transition, and after using Gerrit along side of an email interface for a little while might convince some to switch to Gerrit.

From a project maintainers point of view, I see an email interface as a pre-requisite as I want to be sure that all review comments are incorporated whether they come from the mailing list or from Gerrit.

Gerrit: Google-style code review meets git

Posted Dec 1, 2009 17:24 UTC (Tue) by spearce (guest, #61702) [Link]

An email interface is planned, but nobody is working on it. Issue 228 [1]
in our issue tracker at least documents the feature request. :-)

Issue 97 [2] might be related, as it talks about accepting a GNU diff
file via a form upload. That's probably most of the effort required
to also accept patches off an email list.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds