6 ms·

have a look at gerrit[1] if you are a git user. it's a complete rewrite of rietveld (in java) and tied closely to git which is because the main contributor is S

have a look at gerrit[1] if you are a git user. it's a complete rewrite of rietveld (in java) and tied closely to git which is because the main contributor is Shawn Pearce (who is also main contributor to git[2]). [1]: http://code.google.com/p/gerrit/ http://code.google.com/p/gerrit/ [2]: http://git-scm.com/about http://git-scm.com/about

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
bdb 16y ago
Gerrit feels so... heavy. Are any of you using it at a small-ish company? Does it get in the way of getting work done?
- suraj 16y ago
  I have used it for a team of 10 people (at 2 locations) and it actually reduced some overhead in communication. I had set it up on a desktop machine for about 2 months and only adjustment I needed was to increase heap size for JVM. If you are using git, give it a try. It is dead easy to set up.
- dlsspy 16y ago
  We've been using it for a small, but growing team. It's been beneficial every step along the way.
gorset 16y ago
I'm very unhappy with gerrit. It doesn't support git style branches, and instead uses a made up "Change-Id" scheme where you embed some magic in commit messages. If you want to fix issues with a commit after a review, you can reuse this "Change-Id" to update the changeset for the review. 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.
- dlsspy 16y ago
  I reject those commits right off the top. 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.

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

bdb 16y ago

Gerrit feels so... heavy. Are any of you using it at a small-ish company? Does it get in the way of getting work done?

suraj 16y ago
I have used it for a team of 10 people (at 2 locations) and it actually reduced some overhead in communication. I had set it up on a desktop machine for about 2 months and only adjustment I needed was to increase heap size for JVM. If you are using git, give it a try. It is dead easy to set up.
dlsspy 16y ago
We've been using it for a small, but growing team. It's been beneficial every step along the way.

gorset 16y ago

I'm very unhappy with gerrit. It doesn't support git style branches, and instead uses a made up "Change-Id" scheme where you embed some magic in commit messages. If you want to fix issues with a commit after a review, you can reuse this "Change-Id" to update the changeset for the review. 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.

dlsspy 16y ago
I reject those commits right off the top. 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.