3 ms·

What is Gerrit and why are they using it instead of just using GitHub?

natebc 3y ago
https://www.gerritcodereview.com/about.html https://www.gerritcodereview.com/about.html It's a code review platform used heavily by Google.
- laurels-marts 3y ago
  If it's closed-source project store it in whatever proprietary platform you want. But if it's open-source and you want contributors the just do everyone a favour and use the de-facto platform.
  - bqmjjx0kac 3y ago
    Gerrit is significantly nicer to use. It keeps track of each patch set you upload and lets you diff between them. GitHub seems to just... forget about everything but the two most recent uploads.
  - danpalmer 3y ago
    I see your point, but some of the biggest open source projects don’t use the GitHub workflow: Chromium, Linux, Go, Android, and so on. The GitHub workflow is great for many projects but doesn’t really scale to thousands of contributors, every large project on GitHub (e.g. Kubernetes, VSCode) end up with loads of tooling, loads of pain, and a bad experience for contributors and maintainers. Also Gerrit isn’t proprietary. It’s git for the VCS and gerrit is just a web app on top of that. It just works in a different model to GitHub.
  - TheDong 3y ago
    The linux kernel, which is open source and does want contributors, is doing more-or-less just fine with an email-based PR and review flow. If it's an open source project, it should be using an open source review platform that allows improvements and specialization of the code hosting too. Using github, where the review tools are bad and can't be improved by an outsider, is a slap in the face to open source. Frankly, I'm tired of people using github. The fact that it still doesn't have any idea of patchsets and diffs between them is cripplingly bad (i.e. you force push a new version of your change, there's no easy way to review the diff between the old and new version of your change). Having to use yet more third party tools, like https://reviewable.io https://reviewable.io, isn't an answer to this, it's just a sign that github should be open source so these could be forks or first-party tools. It's also just insulting for an open source project to force people to use a proprietary platform owned by microsoft.
  - yjftsjthsd-h 3y ago
    But gerrit is open source, not proprietary. In fact, github is a proprietary platform that we shouldn't make essential to FOSS projects.
tylerhou 3y ago
Gerrit is a Google-built tool for code review that has UX similar to their internal code review tool Critique. I prefer to use Gerrit because, frankly, GitHub code review is awful. 1. As an author, responding to review feedback is a back-and-forth between my editor and the code review tool. I tend to write responses to comments while I edit code. When I'm satisfied and I've pushed my new code, I want to send all of the responses at once -- especially if two responses depend on each other. GitHub doesn't let me draft responses and then send all (unless I let the responses hang in the HTML input, which is risky). 2. On GitHub, there is no great way to update a PR with changes. Yes, I could push a new commit to the branch. But then I need to squash commits (I don't want the "bad" commits to land in main). When GitHub squashes commits, it concatenates the commit messages which is NOT what I want. (I care about my commit messages being precise and accurate.) I also can't reword my original commit message. So I guess I have to force push. But this makes it harder for collaborators to understand what has changed because GitHub garbage-collects old commits; sometimes I get the message that the old commit can't be found. On Gerrit, I (non-force) push to a "magic" ref which updates the PR for me. 3. As a code reviewer, it's really hard for me to understand what the PR author has changed since the last review. I think part of this is that by default GitHub shows the thread for a PR instead of the code. The thread view has a bunch of whitespace that makes it difficult to concisely understand what has changed. For an interface I use regularly, I really want a condensed view. Gerrit: https://chromium-review.googlesource.com/c/chromium/src/+/4658680 https://chromium-review.googlesource.com/c/chromium/src/+/46... 4. Finally, Gerrit has a nice interface (like Critique) that concisely shows the PR history and what each individual is working on. (Here's a person picked randomly from Chromium code review: https://chromium-review.googlesource.com/q/owner:katzz@google.com https://chromium-review.googlesource.com/q/owner:katzz@googl...). It's really useful for understanding what changes were made/are in progress. Again, GitHub's UI has so much whitespace that is definitely prettier but not useful for a tool that should help my productivity, not hurt it.
- madeofpalk 3y ago
  It doesn’t help with any of the other comments, but doesn’t GitHub let to customise the merge commit message, even when you squash-and-merge?

https://www.gerritcodereview.com/about.html https://www.gerritcodereview.com/about.html It's a code review platform used heavily by Google.

laurels-marts 3y ago
If it's closed-source project store it in whatever proprietary platform you want. But if it's open-source and you want contributors the just do everyone a favour and use the de-facto platform.
- bqmjjx0kac 3y ago
  Gerrit is significantly nicer to use. It keeps track of each patch set you upload and lets you diff between them. GitHub seems to just... forget about everything but the two most recent uploads.
- danpalmer 3y ago
  I see your point, but some of the biggest open source projects don’t use the GitHub workflow: Chromium, Linux, Go, Android, and so on. The GitHub workflow is great for many projects but doesn’t really scale to thousands of contributors, every large project on GitHub (e.g. Kubernetes, VSCode) end up with loads of tooling, loads of pain, and a bad experience for contributors and maintainers. Also Gerrit isn’t proprietary. It’s git for the VCS and gerrit is just a web app on top of that. It just works in a different model to GitHub.
- TheDong 3y ago
  The linux kernel, which is open source and does want contributors, is doing more-or-less just fine with an email-based PR and review flow. If it's an open source project, it should be using an open source review platform that allows improvements and specialization of the code hosting too. Using github, where the review tools are bad and can't be improved by an outsider, is a slap in the face to open source. Frankly, I'm tired of people using github. The fact that it still doesn't have any idea of patchsets and diffs between them is cripplingly bad (i.e. you force push a new version of your change, there's no easy way to review the diff between the old and new version of your change). Having to use yet more third party tools, like https://reviewable.io https://reviewable.io, isn't an answer to this, it's just a sign that github should be open source so these could be forks or first-party tools. It's also just insulting for an open source project to force people to use a proprietary platform owned by microsoft.
- yjftsjthsd-h 3y ago
  But gerrit is open source, not proprietary. In fact, github is a proprietary platform that we shouldn't make essential to FOSS projects.

tylerhou 3y ago

Gerrit is a Google-built tool for code review that has UX similar to their internal code review tool Critique. I prefer to use Gerrit because, frankly, GitHub code review is awful. 1. As an author, responding to review feedback is a back-and-forth between my editor and the code review tool. I tend to write responses to comments while I edit code. When I'm satisfied and I've pushed my new code, I want to send all of the responses at once -- especially if two responses depend on each other. GitHub doesn't let me draft responses and then send all (unless I let the responses hang in the HTML input, which is risky). 2. On GitHub, there is no great way to update a PR with changes. Yes, I could push a new commit to the branch. But then I need to squash commits (I don't want the "bad" commits to land in main). When GitHub squashes commits, it concatenates the commit messages which is NOT what I want. (I care about my commit messages being precise and accurate.) I also can't reword my original commit message. So I guess I have to force push. But this makes it harder for collaborators to understand what has changed because GitHub garbage-collects old commits; sometimes I get the message that the old commit can't be found. On Gerrit, I (non-force) push to a "magic" ref which updates the PR for me. 3. As a code reviewer, it's really hard for me to understand what the PR author has changed since the last review. I think part of this is that by default GitHub shows the thread for a PR instead of the code. The thread view has a bunch of whitespace that makes it difficult to concisely understand what has changed. For an interface I use regularly, I really want a condensed view. Gerrit: https://chromium-review.googlesource.com/c/chromium/src/+/4658680 https://chromium-review.googlesource.com/c/chromium/src/+/46... 4. Finally, Gerrit has a nice interface (like Critique) that concisely shows the PR history and what each individual is working on. (Here's a person picked randomly from Chromium code review: https://chromium-review.googlesource.com/q/owner:katzz@google.com https://chromium-review.googlesource.com/q/owner:katzz@googl...). It's really useful for understanding what changes were made/are in progress. Again, GitHub's UI has so much whitespace that is definitely prettier but not useful for a tool that should help my productivity, not hurt it.

madeofpalk 3y ago
It doesn’t help with any of the other comments, but doesn’t GitHub let to customise the merge commit message, even when you squash-and-merge?