On 2025-08-16 12:42:53 -0700 (-0700), Russ Allbery wrote: [...]
That said, GitHub at least has gotten a lot better over the years. In particular, they added incremental reviews (only showing you the bits that have changed since your previous review), commit-by-commit review (or maybe that's always been there and I just figured out how to find it), and merge queues, which get pretty close to the UI experience that I liked with Gerrit.
[...]
The more fundamental difference with Gerrit's approach, for me, is that you're proposing and revising a patch or series of patches and adjusting it until it appears the way you and reviewers want it to appear in the target branch's history. Gerrit supplies tooling necessary for comparing between arbitrary revisions of a patch, so there's no need to heap on fixes in subsequent commits, you just revise the commit (or series of related commits) repeatedly until it's in good enough shape to be merged.
This is essentially the workflow used on LKML as well, but with a stateful service and Git interface rather than a mailing list full of threads with attachments. By comparison, I find the common GitHub and GitLab PR/MR workflows extremely frustrating in the way that they fail to preserve state or allow fluid reviewer discussion across revisions (at least GitHub has finally stopped vanishing all the comments when you rebase!), but I understand it's all a matter of personal preference and what sorts of workflows you get accustomed to.
For me, doing code review long before GitHub existed, it has always seemed like a social media platform with code hosting bolted on, struggling to catch up with the features of review-oriented platforms. Sadly, GitLab copied much of GitHub's design mistakes for the sake of user familiarity/acquisition.
-- Jeremy Stanley
signature.asc
Description: PGP signature
