Hacker News Reader

Comment by xvilka | Hacker News Reader

All everything aside, reviewing big pull requests on GitHub became nearly impossible - even with the simplest change view it makes you spend too much time on waiting for the page to load the necessary file first. The performance degraded significantly from what was the experience from 10 years ago. UI became an absolute mess. Maybe even vibe-coded.

View on HN

Is there a good code review tool out there? The best one I've used is Gerrit, at least it has a sensible design in principle. Aside from that I've only used GitHub and Gitlab which both seem like toys to me. (And mailing lists, lol).

But the implementation of Gerrit seems rather unloved, it just seems to get the minimal maintenance to keep Go/Android chooching along, and nothing more.

My old job used Gerrit, and new job uses Gitlab. I really miss the information density and workflow of Gerrit. We enforce fast forward merges and squashing for MR's anyways, so we just have an awkward version of what Gerrit does by default.

Gitlab CI is good but we use local (k8s-hosted) runners so I have to imagine there's a bunch of options that provide a similar experience.

You can't "stack" MRs in Gitlab though right? So if you're merging a complex feature you just have one huge mega commit?

What do you mean by "stack" MRs?

Just like with plain git - in GitLab you can merge a branch that has multiple separate commits in it. And you can also merge (e.g. topical/feature) branches into one branch - and then merge that "combined" branch into main/master.

Though most teams/project prefer you don't stretch that route to the extreme - simply because it's PITA to maintain/sync several branches for a long period of time, resolving merge conflicts between branches that have been separate for a long time isn't fun, and people don't like to review huge diffs.

I guess what I'm saying is: for very large complex features, I don't want one big commit. I want to review a series of commits and then I want to have that series of commits persist in the history.

This is how Gerrit operates "natively" - the commit message and everything is part of the artifact under review exactly like the diff.

If the model is to squash an MR into a single commit before merging it, I'd then want to be able to have MRs that depend on each other.

You can "chain" them and there's some native support for this in Gitlab, but I can't say I've ever tried using it. If I really need a feature branch, I just create a separate branch and target my MR's to that until the whole thing is ready to land in main. Again, it seems less natural to me than how Gerrit does it.

What do people think of ReviewBoard?

We use perforce in work, and we use p4 swarm. It’s unremarkable, hasn’t changed in a decade and just works. Best part of perforce, by far

I miss Gerrit - it was the first code review tool I used at work. Using GitHub and GitLab as subsequent jobs hasn't been fun.

> But the implementation of Gerrit seems rather unloved

There are lots of people who are very fond of Gerrit, and if anything, upstream development has picked up recently. Google has an increasing amount of production code that lives outside of their monorepo, and all of those teams use Gerrit. They have a few internal plugins, but most improvements are released as part of the upstream project.

My company has been using it for years, it's a big and sustained productivity win once everyone is past the learning curve.

Gerritforge[0] offers commercial support and runs a very stable public instance, GerritHub. I'm not affiliated with them and not a customer, but I talk to them a lot on the Gerrit Discord server and they're awesome.

[0]: https://www.gerritforge.com/

While I'm not annoyed by the slowdown that much, what made me not trust them anymore is being careless with the system. For example I did a review recently on a PR where the collapsing sections were not visible and made 2 patch fragments look like continuous code. I commented that this makes no sense and won't run... only to look like an idiot later. Fortunately the issue was fixed by the time I looked at the PR again, but still, much less trust now.

Quick tip: If you type .patch after the PR url it gives you a git patch. Do curl <github patch> | git am and you can apply and review it locally.

No need for that. Just install the VSCode GitHub extension and you can just directly open them. It even supports comments.

Hell even if you don't use VSCode there are much better options than messing around with patch files.

When I read

> No need for that.

I generally expect a less complex solution, it seems like your is more complex (easiness is arguable though)

VSCode is not a “given” - I certainly don’t use, or ever intend to use, it.

Patch files are excellent for small diffs at a glance. Sure, I can also `git remote add coworker ssh://fork.url` and `git diff origin/main..coworker/branch`, and that would even let me use Difftastic (!), but the patch is entirely reasonable for quick glances of small branch diffs.

Heck, you can't - to the best of my knowledge - even comment on changes in a commit instead of just the sum total of changes in a pull request. It's as if GitHub expects everyone to use squash on merge workflows, which is insane for developers who know how to structure commits and write commit messages. Oh yeah, and you can't comment on commit messages neither. In Gerrit (which otherwise has plenty of problems, too), they show up as part of the patch.

Most developers haven’t seemed to use another workflow unfortunately—& they scoff at suggesting the only workflow they know could be wrong.

In the "files changed" view on GitHub you can view the PR commit-by-commit and comment on that commit's change

They even have the gall to call it an improved UI for reviewing large pull requests. They must have let UI designers who've never written code before design it.

IME those types of UI designers are way way way way more common, very few designers seem to understand the platform they are designing on and care more about aesthetics rather than proper platform designs.

That's what happens when the whole company uses high-end macbooks and nobody has an older PC. It's been noted thousands of times on HN but these US companies make money head over fist and do not give a single damn about people on "lower" end devices.

Large GitHub PRs are miserably slow even with a maxed out Mac Studio on gigabit fiber with single-digit ms ping to their server. It’s not an example of something that works well on high-end hardware but scales down poorly.

> The performance degraded significantly from what was the experience from 10 years ago. UI became an absolute mess. Maybe even vibe-coded.

Just like Microsoft Windows. I wonder if they are the same company. /s

Reply on news.ycombinator.com