You have some points, for some I do think it isn't as bad as you write. FWIW, some comments inline.
> - You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution.
You can use tools like public-inbox or lei, the former is hosted for bigger projects on https://lore.kernel.org/
If you're interested, see also https://people.kernel.org/monsieuricon/lore-lei-part-1-getti...
And sure subscribing for a drive by submission is rather overkill, but if one contributes more than a few patches, setting up a filter is to easy with mailing lists that I don't think one can just hand wave that away as an "unreasonable" solution. List have a dedicated List-Id header, so one can easily filter them in a targeted way.
What I want to convey actually is, that yes, there can be improvements made here, but doing so isn't impossible just because the message medium is decentralized mail vs. a centralized HTTP API.
- Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email.
Hard disagree on that being the general case. Even getting Thunderbird to send plaintext is simple and only one setting, and there are mailers like aerc [0] or neomutt that are really well suited for an integrated mail + apply + review setup.
But sure, there are some bad apples, especially most web mailer.
[0]: https://aerc-mail.org/
[1]: https://neomutt.org/
> - The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one.
Yes, for sending a new revision this is highly wanted – please do NOT send new patch revision to the same thread, that just crowds review and adds nothing. Simply add a changelog to the previous revision in the cover-letter and/or in each patch, i.e., after the message, below "--" and before the diff-stat, as there they won't get into git, such changes are meta info relevant for review, not for the git history.
> - Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version.
I have reviewed lots of patches via mailing list, it's really nice and depending on the patch one can review directly inline or apply (save + `git am`, or directly `git am` depending on your mailer). IMO much higher quality of life than with the classic Git(La|Hu)b forges.
> - Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge".
No it really isn't, I'm doing that since years a dozen+ time a day, and it is as easy now as it was back then when I started.
If I use thunderbird I got my one directory for it, so I just mark all, save and execute `git am ~/t/aaa/*` in the repo. When I use aerc, then it's even simpler, it has built-in helpers for doing this easily.
Here I can manage simple conflicts easily (e.g., using three-way-merge) on GitHub conflicts are a bigger PITA and need lots of manual intervention from me or waiting on the submitter, meh. Also, the interface often loads weirdly, as they manage their own history as a single page app which often gets in a state where button presses won't do much.
> - You can run into issues if your lines of code are more than 78 characters long. I used git-send-email to send in a patch once that had this, but the email client of the receiver couldn't handle long lines, so I had to resend it with the patch as an attachment.
git send-email uses base64 encoding for that, if the mail user agent of your recipient cannot handle that it's like their broswer cannot handle HTTP/1.1, switch that stuff immediately.
> - Some mailing lists require you to subscribe before you can send a patch. And if the list is pretty active, that can flood your inbox. See my first point.
Yeah, sadly sometimes needed for anti-spam measurements, here I agree fully that this isn't ideal, but FWIW, for Git(Hu|La)b I also need to create a account and fork, so it's not exactly zero work there too, but yeah, due to SSO and gaining access to many projects, vs. just one for a subscription that is not really comparable..