[1]: http://code.google.com/p/gerrit/ [2]: http://git-scm.com/about
It get worse. If you have a nice branch with several commits, they must all be reviewed separately with little help to review the branch as a whole. This feels like a throwback to the old days with CVS and patch-sets. Branching and merging suddenly becomes expensive.
If you combine this with a policy of auto-merging upon successful review, you are basically screwed if you have multiple depending commits. You must use rebase and squash to make it livable.
Sorry for the bitterness :-) I just had to review a single commit with 4000+ lines in gerrit.
The things you are complaining about are all things that I enjoy about gerrit. I tend to rebase on pull and use cherry-pick as the submit mechanism so it fits naturally into the flow of my groups.
As much as I like Gerrit I don't think I can use it for our team because Gerrit wants you to review commits, and our team works in terms of whole branches. Reviewing your individual commits made early in the branch history probably isn't useful as bugs may be fixed--or the code entirely changed--by later commits. Anyone else have this problem with Gerrit, reviewing commits vs. reviewing branches?
If you wait until a branch is done, then reviewers are being asked to look at big chunks of code. That is a lot more effort, and it is harder to get reviewers to do it. And when they do do it, it is harder to get them to do a thorough job of it. Furthermore when they notice design issues, it is harder to get developers to go back and redo all of their working code to make it better.
Therefore if you want effective code review, you need to review early and review often. The smaller a change is, the easier it is to review, the easier it is to be thorough, and the easier it is to accept suggested changes.
My conclusion is therefore that choosing to do code review after the fact means that you are guaranteeing no proper code review. But when you review early - literally on every commit - it is then much easier to maintain a truly effective code review process. It initially "feels" much heavier. But after you get in the rhythm, your code will be much, much improved.
- dev works on a feature branch, making multiple commits and pushes
- once ready, squash all the commits and submit it to gerrit
[- perhaps have hudson/jenkins run the unit tests at this point automatically]
- have the code review in gerrit
- once the review is done, gerrit would merge it into the develop or master branch (depending on your git workflow)
That approach blends in nicely with git-flow (1). If you want to be sure that no single dev is pushing to the develop or master branches you'd need to setup per-branch permissions, which can be done with gitolite (2). Too bad github (even the self-hosted version) doesn't support per-branch permissions, which forces organizations that use it and only want gerrit to be able to push into the main branch to do excessive repo forking instead of using feature branches. Also I'd love to be able to do ad-hoc code reviews in github, as the interface is the most beautiful of all imo.
[1] http://nvie.com/posts/a-successful-git-branching-model/, https://github.com/nvie/gitflow, http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flo...