Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > The problem is not Perl, but how fiddly it is to set up. And that you lose > all the niceties of an email client (e.g. when you want to add a comment > before the diff stat that is not intended to become a part of the commit > message). Just this part. I do not think that is fair to send-email. You are blaming its "feature" that allows it to drive format-patch, which I do not consider is the proper part of the command and to which I kept saying from the early days of its introduction that I'd never use it and I think we should discourage its use exactly because it encourages a bad workflow (i.e. you skip the final proof-reading before sending out, and you cannot add footnote comments). Treat it like an MSA just like Thunderbird, just designed to be more suited to send out patches without corruption, and you will be OK. You work, commit and write your message with your favourite editor, do format-patch, reword or add footnote with your favourite editor, and then send it out. You can avoid letting other MSAs that may corrupt whitespaces touch what you will send out if you used send-email, but that is not mandatory. As long as your favourite MSA does not corrupt your message, you can use it. Somebody mentioned "configuring it is hard--why does the user have to know SMTP subtleties", and that may be a valid complaint against the primary part of send-email. The solution for that is not to discard it with bathwater, but make it just as easy as other MSAs, say, Thunderbird, to configure for an average user who can configure these other MUAs. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html