> Almost everyone has a web browser installed. Not everyone has a MUA installed.

It shouldn't be an issue to install one. A somewhat related example I recently came across was when I had to install Google chrome to use a feature of Slack that wasn't supported in Firefox. To get around that issue, I installed chrome. If I had to, I would have also had to set up the necessary proxy configuration for that browser to work (though that wasn't the actually the case).

Similarly, if one wants to contribute to a project that requires emailed patch files, then part of the process should be installing and setting up a MUA if the web based front-end doesn't work properly.

> This was the step I missed, thanks. This could work. You now need to keep your patches around, but it could work.

I think it's easier than having to retrieve the original message via IMAP, POP, or HTTP and copying its message-id value :)

> I meant stable across local changes to the commit. I didn't realize you were serializing this commit hash to some file and fetching it from the file later.

Typically, when contributors do a re-roll of a patch set, they effectively either use git commit --amend or git rebase to update the commits in the branch they're working on. The updated patchset is sent to the mailing list and pulled down by reviewers and applied to their working tree (which results in a commit with the same change, but a different SHA1). This is unlike the case where one runs git fetch or git pull and pulls down the commits and gets the commits with the same SHA1 applied to their local copy.

In other words, the SHA1 value isn't that important other than to serve as a unique value of the message-id header.

> You can use email effectively without a local email client, however.

I use both web based clients (hotmail, gmail) and a locally installed MUA (thunderbird). I can say that I have a better user experience with the MUA compared to the web based front ends.

For the purposes of patch submission, reviewing, etc, I think that web based clients are really not sufficient due to the lack of threading (as I would see it in a traditional email client).

> it's that you're asking people to effectively change their entire workflow for interacting with email just so that they can contribute.

There are a number of steps one has to take to contribute to a project. Reading documentation, installing the software, documenting the bug they're proposing to fix, discussing the approach with project maintainers, implementing the change, testing the change, submitting the fix, responding to reviews, etc.

Just submitting the patch is a small part of the overall process. For example, a contributer would have to set up the development environment such that they can run the tests that come with the project. That in itself could be a bit more work than figuring out how to use git send-email to submit the patches.

> MUAs are harder to set up. Refer to aforementioned points about blocked ports, confusing IMAP/POP3 deletion semantics

It's easy enough to see whether or not ports are blocked by attempting to connect to the SMTP, POP/IMAP servers. As for the "confusing [...] deletion semantics", I have never encountered an issue where I accidentally deleted all my email in the last 22 some years of using email while using my local MUA.