Koopa 🌸i think that GitHub has firmly established some unnecessary preconceptions about how code review should work
if you look at the code forges that came after (GitLab, Gitea), most of them copy the Pull Request interface because it's familiar and easy to use
even though PRs as a concept exist with email-based workflows, [0] these modern code forges assume that PRs are the finest granularity you are working at. there are no accommodations for atomic commits, despite some of Git's tools being designed for this. [1]
having used it over the summer, i do think that #gerrit gets it right. but nobody wants to copy Gerrit when making a comprehensive forge. the closest thing we have is #sourcehut (uses email for submitting patches), which is not really what i want.
as it stands, Gerrit appears to be super underutilized in open-source spaces. the only project i'm aware of (that isn't being operated by a company) that uses it is #TouchHLE by @hikari. [2] aside from the friction of setting Gerrit up to work with a more featureful forge, i think the reason for this may be a resistance to more bureaucracy when working on fun stuff.
but like. reviewing GitHub PRs with more than one commit kinda sucks. yet you don't want to go full Gerrit (+cgit) either, because Gerrit's pipeline integration appears to be pretty primitive. also, it's nice to have a repo browser other than cgit
i think that my ideal setup would be a federated (!) code forge with gerrit-style code review of individual commits and modern CI integration
[0] https://git-scm.com/docs/git-request-pull
[1] https://gerrit-review.googlesource.com/Documentation/intro-rockstar.html
[2] https://github.com/touchHLE/touchHLE
Dekazeta 
Jessie Nabein (Old Account)
Edu Garcia @ MicroProse
appgefahren.de - Tech-Blog
