[HN Gopher] Codereview: Should the Go project stop importing Git...
___________________________________________________________________
Codereview: Should the Go project stop importing GitHub PRs?
Author : nateb2022
Score : 14 points
Date : 2023-07-05 21:18 UTC (1 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| laurels-marts wrote:
| What is Gerrit and why are they using it instead of just using
| GitHub?
| tylerhou wrote:
| 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.
|
| 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/+/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@googl...). It's really
| useful for understanding what changes were made/were 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 wrote:
| 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?
| natebc wrote:
| https://www.gerritcodereview.com/about.html
|
| It's a code review platform used heavily by Google.
| laurels-marts wrote:
| 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.
| danpalmer wrote:
| 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 wrote:
| 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,
| 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 wrote:
| But gerrit is open source, not proprietary. In fact,
| _github_ is a proprietary platform that we shouldn 't make
| essential to FOSS projects.
| bqmjjx0kac wrote:
| 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.
| PossiblyKyle wrote:
| Admittedly I don't have experience contributing to FOSS projects
| (yet), but like many companies we use the feature branch
| workflow, and have minimal conflicts; both on tasks and in the
| code itself. The reason is (and I'm stating the somewhat obvious)
| that we have engineering managers whose primary job is
| coordinating the tasks between teams and within each team. This
| is done externally via Jira, and to me it reflects on a weak spot
| of GitHub if it wants to be "the place to manage a project" -
| it's good for managing a code base but lacks the tools to manage
| it as a project/product.
| madeofpalk wrote:
| GitHub has been working on this recently and made pretty
| significant improvements with the new Org Projects and
| Tasklists in issues.
|
| Project management for my day job happens entirely in GitHub
| and while it's not perfect, it's significantly better than it
| was even 12 months ago.
| TheBrokenRail wrote:
| I've never contributed to Go before, but from reading this, I
| have to wonder who thought this system was a good idea.
|
| From the sounds of it, the _only_ situation where this PR-
| mirroring works properly, is PRs without any comments, which I
| imagine are quite rare. But if your PR does have comments, then
| you not only have to sign up for Gerrit anyways, but you 're also
| responsible for keeping the GitHub PR and Gerrit PR in sync. That
| sounds horrible.
| reichstein wrote:
| There are tools to automatically update the Gerrit change when
| the GitHub PR is updated. If you keep the comments on GitHub,
| eventually you may end up with an acceptable PR, which you have
| continuously tested in Gerrit too. Then you just land that.
|
| If you want to do the reviews in Gerrit, then that's more
| annoying, but the changes can still be made on GitHub.
___________________________________________________________________
(page generated 2023-07-05 23:02 UTC)