Generally the ones I don't mind losing. If anyone can't figure out how to send a git pull request or patchset by email, I'm happy for them to email me with questions on how to, which I will answer as best I can.
I can figure out how to send you a patch set via email (see my Linux kernel contributions), but if I can avoid doing that, sure as heck I will. Your project must be really important to me, or I have to get paid.
Based on your first example of running git send-email without providing it any patch files or revision list, you appear to be making the assumption that someone doesn't bother reading the documentation before using the tool.
This would be like someone trying out make the first time and not realizing why it isn't working becaue they didn't realize they need literal tab characters in the make file for the rules to work. But if they don't read the documentation, there's no way they would know that.
The real problem is people trying to figure out how tools work by experimentation as opposed to reading documentation. If someone reads the documentation of git send-email and the project's contrib document contains the preferred settings for that utility, then submitting patches should not be an issue.
That's a valid observation of one of the reasons I won't use git-send-email.
I have limited mental resources, and given the choice between a tool where I have to spend half an hour before I can begin using it, and a tool which will guide me, I'll always choose the latter. After I'm done, I can even forget I ever used the latter tool! It's a boon for one-offs.
Keep reading, there's more criticism on other aspects of the tool.
After reading through the rest of the post, I do see your point. When I last tried it, I thought that most of the email formatting should be done with git format-patch and then git send-email should be used to actually send the email without having to answer any questions.
That would address one of your concerns about saving the email on disk and also ensuring that the headers have the correct contents.
If the project's contrib document contained information about what settings to use for format-patch and send-email, then the process would be much more seamless. I haven't looked at the kernel (or subsystems) documentation on that. The git project itself doesn't seem to contain that information though.
Regarding your other point about using your email client to handle sending the emails, git does have a utility called imap-send that would allow you to upload the patches to an IMAP folder, which, I believe, would allow you to then send the messages using your MUA of choice instead of git send-email.
You could mail patches as plain text attachments, if there are concerns about the clients mangling them. You could also try some easier plain-text clients instead of mutt. Claws mail is a simple GUI based one.
Honestly, if you can't be arsed to format an email then why should you expect anyone to spend the effort to review your patches and maintain your additions going forward.
Drew DeVault created this[1] to help people start using git send-email. I'm not sure if it works for the purpose of contributing to your project, but it may save you from having to explain the same thing repeatedly :)
I want to add the guide to submitting patches for the Linux kernel [1]. It contains a bit more finer points, in addition to what's on the site you linked.
