5 ms·

I think Gerrit is a really impressive piece of software. Please correct me if I'm wrong but if you're looking for a major user of Gerrit I believe the Android

by draebek 16y ago

I think Gerrit is a really impressive piece of software. Please correct me if I'm wrong but if you're looking for a major user of Gerrit I believe the Android OSP uses it. 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?

btilly 16y ago
I'm sorry, but I think that your team has this backwards. 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.
- dkl 16y ago
  We use gerrit at my company, and what you say is true. Developers are told to do one feature or bug fix per commit/gerrit change. It really does help with the review process and things move much faster.
metachris 16y ago
No matter how often you want to review code, I think it could work for your team like this: - 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/ http://nvie.com/posts/a-successful-git-branching-model/, https://github.com/nvie/gitflow https://github.com/nvie/gitflow, http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flo... [2] https://github.com/sitaramc/gitolite https://github.com/sitaramc/gitolite

by draebek 16y ago

btilly 16y ago

I'm sorry, but I think that your team has this backwards. 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.

dkl 16y ago
We use gerrit at my company, and what you say is true. Developers are told to do one feature or bug fix per commit/gerrit change. It really does help with the review process and things move much faster.

metachris 16y ago

No matter how often you want to review code, I think it could work for your team like this: - 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/ http://nvie.com/posts/a-successful-git-branching-model/, https://github.com/nvie/gitflow https://github.com/nvie/gitflow, http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flo... [2] https://github.com/sitaramc/gitolite https://github.com/sitaramc/gitolite