[palata]

> I would love to do a whole blog post about how mailing list collaboration works and how cool various aspects of it are, but that’s for another time.

This is actually the part I would be interested in, coming from a GitHub cofounder.

[schacon]

You'll be the first to know when I write it. However, if anything, GitHub sort of killed the mailing list as a generally viable collaboration format outside of very specific use cases, so I'm not sure if I'm the right person to do it justice. However, it is a very cool and unique format that has several benefits that GitHub PR based workflows really lose out on.

[jen20]

By far my biggest complaint about the GitHub pull request model right now is that it doesn't treat the eventual commit message of a squashed commit (or even independent commits that will be rebased on the target) as part of the review process, like Gerrit does. I can't believe I'm the only person that is upset by this!

[schacon]

If this is something you're interested in, you may want to try the patch-based review system that we recently launched for GitButler: https://blog.gitbutler.com/gitbutlers-new-patch-based-code-r...

[jen20]

This does look interesting! I’ll take a closer look.

[bhasi]

You are not alone. Coming from Gerrit myself, I hate that GitHub does not allow for commenting on the commit message itself. Neither does Gitlab.

Also, in a PR, I find that people just switch to Files Changed, disregarding the sequence of the commits involved.

This intentional de-emphasis of the importance of commit messages and the individual commits leads to lower quality of the git history of the codebase.