8 ms·

I'm curious what Gerrit gets them that Github doesn't have natively, too.

pwnna 12y ago
Gerrit works well for a project that has many different repositories, as you can do code review all in one screen. I did some CyanogenMod development and I really liked gerrit, albeit its poor performance on Firefox (client side app that had weird JS freezes in fx only..)
bradfitz 12y ago
Go team member here. I've used five different code review tools, and Github is the worst of the five. I regularly bug them (Github) about this, and they know it. I hear rumors they've been working on it a lot. Github's review mechanisms barely scratch the surface of what's possible.
- Locke1689 12y ago
  If any of the other ones are public, which did you like best? IIRC, Mondrian was good, but not great.
  - zippergz 12y ago
    Mondrian is the best code review tool I've ever used, but I'll admit that could be damning with faint praise... I'm very curious to hear what the better options are, because we use Github at my current company and I would go back to Mondrian in a heartbeat.
  - bradfitz 12y ago
    From best to worse, in my experience: 1) Google's current internal one 2) Gerrit (open source, to be used by Go) 3) Google's old one (Mondrian) 4) Rietveld (open source, but run for free at codereview.appspot.com) 5) Github I would totally suspect that Phabricator or Review Board would be well above Github (as are 1-4 in my list), but I don't know where. I have little desire to use or explore new code review systems at this point. Four per day is enough for me at the moment.
    - piotrkaminski 12y ago
      In case you do want to try out another one at some point, I built https://reviewable.io https://reviewable.io to take some of my favorite features from Google's internal tool but integrate seamlessly with GitHub.
    - maherbeg 12y ago
      Review Board isn't as good as it could be. Sometimes it's diffing tool provides far too much noise to be useful.
- chenglou 12y ago
  Have you ever, by coincidence, used Phabricator? If so, what's your opinion of it? I've used Phabricator full-time for a while and it's been really a joy.
enneff 12y ago
There are a lot of things lacking about GitHub's code review process (pull requests). Off the top of my head: - Merging a pull request (almost) always creates a merge commit, polluting the change history. Gerrit will automatically rebase the changes atop the master branch head, leaving a nice linear history. - Pull requests require the contributor to create a public fork of the repository they're committing to. I can see how this works for some people, but I find it gross for each contributor to the Go project to have their own public fork. What a mess. - Comments on pull requests are sent as soon as they are created. Gerrit allows you to make many comments on a change, as drafts, and then send them all in one go, sending just a single email. This is much easier to manage for a large project. - Gerrit has the notion of multiple 'patch sets' for a particular change, and you can see diffs between patch sets, so it's much easier to progressively review large changes. And there are many other small issues with the GitHub pull request process that make it untenable for the Go project.
- reledi 12y ago
  > Pull requests require the contributor to create a public fork of the repository they're committing to. You can create Pull Requests within a repository. You don't need to fork the repository if you have push access.
  - dsymonds 12y ago
    Go contributors will not be pushing to the GitHub repository, nor will have direct commit access to the Gerrit hosted git repository.
- nathany 12y ago
  I'm really curious to give Gerrit a try. Is it like the existing Rietveld system used for Go? - I've been using the "apply mail" flow to avoid merge commits and to squash commits when appropriate (based on Nathaniel Talbott's post http://blog.spreedly.com/author/ntalbott/#.VGVhz5PF_Zs http://blog.spreedly.com/author/ntalbott/#.VGVhz5PF_Zs). It will be nice to have something automatic. - At least contributors with the commit bit can just create a feature branch and a pull request from there. Some open source projects give out the commit bit almost immediately, but with GitHub there's still that initial fork and pull request to prove oneself. Interested to see how Gerrit addresses this. GitHub doesn't have any way to disable pull requests. :-( - I've completely disabled email notifications for this reason. There still can be a huge number of notifications in app or via third-party mobile apps. Rietveld is a lot more sane, I only saw notifications for things I was actively working on. - I usually end up reviewing just the new commits individually. But that requires figuring out which ones I had already reviewed. Not so bad with only a few branches, but I can see it getting out of hand. I really hope people from GitHub are reading this thread as they are working to improve their tools. :-)
krschultz 12y ago
GitHub has the network effect of so many existing repos, but I personally think the issues & code review tools are mediocre at best.
jrockway 12y ago
The key features for me are: 1) The ability to have multiple reviewers, who can provide both human-readable input ("fix this") and machine-readable input ("Code Review +2"). This becomes powerful when you require a couple things to submit, code review and verification that the change works. A TryBot or something can automatically +1 the Verified bit when the tests pass, and the reviewer can +2 the Code Review bit on the assumption that the code compiles and the tests pass. Requiring both makes review easier and the repository less likely to break. Sounds like extra bureaucracy, but it's actually really wonderful. 2) Pushing the onus of merging and submitting to the author, instead of the reviewer. I can say "looks good, fix the merge conflicts" and be done with the review. With Github, the repository owner has to do the merge (or push back and re-review; I pick doing it myself). Github's code review tool is really aimed at accepting or rejecting; not improving. At least how I use it, anyway.
foolfoolz 12y ago
I used to work at a company that did 100% of code reviews on gerrit, and by 100% I mean we had a requirement all commits be approved so I spent a lot of time in gerrit. then I moved to company that uses github. it's really a big shift. GitHub is not as intuitive and It has a long learning curve. a lot of it was time needed to adjust but I really miss gerrit. gerrit makes it so clear what commits need reviews. in github it's just a list of pull requests. did I comment already? does this need approval? is this already approved by someone else? who? all of these are difficult to see in github but instantly obvious in gerrit. then at the code level, gerrit uses my whole browser window so on a 30in I can side by side diff any file. GitHub has a tiny viewport and I'm constantly scrolling. it's not streamlined for reading at all and once 5+ comments are there you can give up on reading the code. gerrit has an upper limit on comments too before the ui overwhelms the code but it's way higher. I think gerrits tools for viewing more lines are better, although phabricators are good. gerrit gives me a copy and paste link to check out exactly the code I am looking at. and I really enjoy the patch set system over additional commits. it's a lot clearer in a back and forth setting to see code evolve over time and digging patches without making entirely new commits. gerrit has built in support for automated and human reviews to leave separate scores. aka, you have to pass the tests and get approval. this doesn't exist in GitHub. extending gerrit with hooks was crucial to our workflow. luckily github delivers there, but as gerrit is open source you can do more to extend it. especially on the ui side. I have to admit at first I was blown away how weak github is compared to gerrit. I could not understand why it's so popular. now after about a year on github I get it, I get why it's popular, but is still years behind gerrit.
- fiedzia 12y ago
  Github is simple and good enough for vast majority of users. Gerrit UI sucks. I really cannot express how much I hate it, and how broken and counter-intuitive it is, after working with github. For new users its just unusable. If github would try to impose it on its users, they'd loose 99% of contributions.
piotrkaminski 12y ago
- GitHub doesn't show you what changed in a PR from the last time you looked at it. You can look through the individual commits, but this can be painful if there's a lot of them, and can easily become impossible if the code was merged, rebased, or squashed. - GitHub sends each comment individually, encouraging "shotgun commenting" instead of a coherent set on the sender side, and leaving the receiver to deal with dozens of individual emails. - GitHub attaches line comments to the deltas, which makes the comments disappear if the underlying code changes. This makes it easy to "lose" a comment during a review, and forget to check that something was fixed properly. Even if a comment survives, GitHub doesn't track (non-) resolution in any way, so it's still easy to forget to take care of stuff. - You can't customize things: can't pick your favorite source code font, the wrapping margin, syntax highlighting colors (as it doesn't have syntax highlighting at all), links that open your editor directly on the correct line, etc. As it happens, https://reviewable.io https://reviewable.io fixes all these, and has a much lighter-weight integration with GitHub than Gerrit does, not to mention a much friendlier UI. And yeah, it's my own project so I'm obviously biased, but check it out if you're annoyed with GitHub's code reviews but Gerrit/Phabricator are too heavy for your needs.

pwnna 12y ago

Gerrit works well for a project that has many different repositories, as you can do code review all in one screen. I did some CyanogenMod development and I really liked gerrit, albeit its poor performance on Firefox (client side app that had weird JS freezes in fx only..)

bradfitz 12y ago

Go team member here. I've used five different code review tools, and Github is the worst of the five. I regularly bug them (Github) about this, and they know it. I hear rumors they've been working on it a lot. Github's review mechanisms barely scratch the surface of what's possible.

Locke1689 12y ago
If any of the other ones are public, which did you like best? IIRC, Mondrian was good, but not great.
- zippergz 12y ago
  Mondrian is the best code review tool I've ever used, but I'll admit that could be damning with faint praise... I'm very curious to hear what the better options are, because we use Github at my current company and I would go back to Mondrian in a heartbeat.
- bradfitz 12y ago
  From best to worse, in my experience: 1) Google's current internal one 2) Gerrit (open source, to be used by Go) 3) Google's old one (Mondrian) 4) Rietveld (open source, but run for free at codereview.appspot.com) 5) Github I would totally suspect that Phabricator or Review Board would be well above Github (as are 1-4 in my list), but I don't know where. I have little desire to use or explore new code review systems at this point. Four per day is enough for me at the moment.
  - piotrkaminski 12y ago
    In case you do want to try out another one at some point, I built https://reviewable.io https://reviewable.io to take some of my favorite features from Google's internal tool but integrate seamlessly with GitHub.
  - maherbeg 12y ago
    Review Board isn't as good as it could be. Sometimes it's diffing tool provides far too much noise to be useful.
chenglou 12y ago
Have you ever, by coincidence, used Phabricator? If so, what's your opinion of it? I've used Phabricator full-time for a while and it's been really a joy.

enneff 12y ago

There are a lot of things lacking about GitHub's code review process (pull requests). Off the top of my head: - Merging a pull request (almost) always creates a merge commit, polluting the change history. Gerrit will automatically rebase the changes atop the master branch head, leaving a nice linear history. - Pull requests require the contributor to create a public fork of the repository they're committing to. I can see how this works for some people, but I find it gross for each contributor to the Go project to have their own public fork. What a mess. - Comments on pull requests are sent as soon as they are created. Gerrit allows you to make many comments on a change, as drafts, and then send them all in one go, sending just a single email. This is much easier to manage for a large project. - Gerrit has the notion of multiple 'patch sets' for a particular change, and you can see diffs between patch sets, so it's much easier to progressively review large changes. And there are many other small issues with the GitHub pull request process that make it untenable for the Go project.

reledi 12y ago
> Pull requests require the contributor to create a public fork of the repository they're committing to. You can create Pull Requests within a repository. You don't need to fork the repository if you have push access.
- dsymonds 12y ago
  Go contributors will not be pushing to the GitHub repository, nor will have direct commit access to the Gerrit hosted git repository.
nathany 12y ago
I'm really curious to give Gerrit a try. Is it like the existing Rietveld system used for Go? - I've been using the "apply mail" flow to avoid merge commits and to squash commits when appropriate (based on Nathaniel Talbott's post http://blog.spreedly.com/author/ntalbott/#.VGVhz5PF_Zs http://blog.spreedly.com/author/ntalbott/#.VGVhz5PF_Zs). It will be nice to have something automatic. - At least contributors with the commit bit can just create a feature branch and a pull request from there. Some open source projects give out the commit bit almost immediately, but with GitHub there's still that initial fork and pull request to prove oneself. Interested to see how Gerrit addresses this. GitHub doesn't have any way to disable pull requests. :-( - I've completely disabled email notifications for this reason. There still can be a huge number of notifications in app or via third-party mobile apps. Rietveld is a lot more sane, I only saw notifications for things I was actively working on. - I usually end up reviewing just the new commits individually. But that requires figuring out which ones I had already reviewed. Not so bad with only a few branches, but I can see it getting out of hand. I really hope people from GitHub are reading this thread as they are working to improve their tools. :-)

krschultz 12y ago

GitHub has the network effect of so many existing repos, but I personally think the issues & code review tools are mediocre at best.

jrockway 12y ago

The key features for me are: 1) The ability to have multiple reviewers, who can provide both human-readable input ("fix this") and machine-readable input ("Code Review +2"). This becomes powerful when you require a couple things to submit, code review and verification that the change works. A TryBot or something can automatically +1 the Verified bit when the tests pass, and the reviewer can +2 the Code Review bit on the assumption that the code compiles and the tests pass. Requiring both makes review easier and the repository less likely to break. Sounds like extra bureaucracy, but it's actually really wonderful. 2) Pushing the onus of merging and submitting to the author, instead of the reviewer. I can say "looks good, fix the merge conflicts" and be done with the review. With Github, the repository owner has to do the merge (or push back and re-review; I pick doing it myself). Github's code review tool is really aimed at accepting or rejecting; not improving. At least how I use it, anyway.

foolfoolz 12y ago

I used to work at a company that did 100% of code reviews on gerrit, and by 100% I mean we had a requirement all commits be approved so I spent a lot of time in gerrit. then I moved to company that uses github. it's really a big shift. GitHub is not as intuitive and It has a long learning curve. a lot of it was time needed to adjust but I really miss gerrit. gerrit makes it so clear what commits need reviews. in github it's just a list of pull requests. did I comment already? does this need approval? is this already approved by someone else? who? all of these are difficult to see in github but instantly obvious in gerrit. then at the code level, gerrit uses my whole browser window so on a 30in I can side by side diff any file. GitHub has a tiny viewport and I'm constantly scrolling. it's not streamlined for reading at all and once 5+ comments are there you can give up on reading the code. gerrit has an upper limit on comments too before the ui overwhelms the code but it's way higher. I think gerrits tools for viewing more lines are better, although phabricators are good. gerrit gives me a copy and paste link to check out exactly the code I am looking at. and I really enjoy the patch set system over additional commits. it's a lot clearer in a back and forth setting to see code evolve over time and digging patches without making entirely new commits. gerrit has built in support for automated and human reviews to leave separate scores. aka, you have to pass the tests and get approval. this doesn't exist in GitHub. extending gerrit with hooks was crucial to our workflow. luckily github delivers there, but as gerrit is open source you can do more to extend it. especially on the ui side. I have to admit at first I was blown away how weak github is compared to gerrit. I could not understand why it's so popular. now after about a year on github I get it, I get why it's popular, but is still years behind gerrit.

fiedzia 12y ago
Github is simple and good enough for vast majority of users. Gerrit UI sucks. I really cannot express how much I hate it, and how broken and counter-intuitive it is, after working with github. For new users its just unusable. If github would try to impose it on its users, they'd loose 99% of contributions.

piotrkaminski 12y ago

- GitHub doesn't show you what changed in a PR from the last time you looked at it. You can look through the individual commits, but this can be painful if there's a lot of them, and can easily become impossible if the code was merged, rebased, or squashed. - GitHub sends each comment individually, encouraging "shotgun commenting" instead of a coherent set on the sender side, and leaving the receiver to deal with dozens of individual emails. - GitHub attaches line comments to the deltas, which makes the comments disappear if the underlying code changes. This makes it easy to "lose" a comment during a review, and forget to check that something was fixed properly. Even if a comment survives, GitHub doesn't track (non-) resolution in any way, so it's still easy to forget to take care of stuff. - You can't customize things: can't pick your favorite source code font, the wrapping margin, syntax highlighting colors (as it doesn't have syntax highlighting at all), links that open your editor directly on the correct line, etc. As it happens, https://reviewable.io https://reviewable.io fixes all these, and has a much lighter-weight integration with GitHub than Gerrit does, not to mention a much friendlier UI. And yeah, it's my own project so I'm obviously biased, but check it out if you're annoyed with GitHub's code reviews but Gerrit/Phabricator are too heavy for your needs.