[u801e]

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.

[dcz_self]

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.

[u801e]

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.