> when you open a Pull/Merge request on those sites. It's easy to apply & download the patch series locally to test it. For E-Mail client integration you need s

> when you open a Pull/Merge request on those sites. It's easy to apply & download the patch series locally to test it. For E-Mail client integration you need something that'll "git am" a range of messages. That's a good point. Like git-am is the inverse of git-format-patch. Unfortunately, no program has been written as the corresponding inverse of git-send-email. If a program like that existed, then one could get feature parity. At least with Thunderbird, one can highlight the messages one wants to save and save them to multiple files in a folder. > Likewise with "git push" to your topic branch updating the PR/MR. Sure you can do this all manually with git-format-patch and git-send-email, but having something that works smoothly takes a lot of work. Based on what I've read, people typically rebase their patch series and push up a new set of emails as a reply to the original patch series. In Github/Gitlab, people typically make an incremental commit and push it up. But, if one wants to maintain a clean commit history for a given feature development branch before it's merged, one will have to rebase and apply those incremental commits to their corresponding base commit. That's trivial if the feature is implemented in a single commit, but a bit more complex if it's multiple commits. The former case has been addressed by Github with their squash before merge feature I believe. The latter case requires manual rebasing (which arguably is more more than just doing it locally before pushing up the next version of the patch set).