Here a few hints to simplify processing of mailed patches:
- When writing the message remember that git will use the mail's subject as the first paragraph of the log message, so don't repeat it in the body.
- Keep the log message formatted to at most 75 columns, if possible. This will ensure the output will properly be displayed in the standard 80 column terminal.
- Do not address the receiver, no mail signatures, no PGP signatures. If you follow these rules your email's body can be used without further editing as the log message greatly speeding up patch handling.
- Don't forget to add a Signed-off-by: Your Name <email@example.com> line
- To faciliate the use of patchwork patches should always be cc'ed to the firstname.lastname@example.org mailing list.
The MIME problem
Documentation/SubmittingPatches in the kernel sources asks patch submitters to
6) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel developer to be able to "quote" your changes, using standard e-mail tools, so that they may comment on specific portions of your code.
But due to brokenness, the most commonly used mail clients generally scramble patches by:
- chopping of trailing whitespace
- converting tab characters to whitespace
- breaking long lines into multiple lines.
which has led to the problem that a very significant fraction of patches had to be rejected simply because they didn't survive email transport. This page is trying to help you to fulfill the apparent contradiction. Keep in mind that the author of this page is a mutt user and would only touch a GUI mail client with a blowtorch.
So you're developed your patches in git, have commited them to your git repository. Then one of the easiest ways to send out is using git format-patch and git send-email. It's going to format your emails the way recommended for submission in Documentation/ and make your life a lot easier.
- Set the formatting to "Preformat"
- Hit Insert/Text File (Alt-I X)
Then at the ghastly gnome dialog hit ^L (secret handshake for the 'developers cant stand it either' shortcut box) and type in the file name.
- Set the formatting mode button just above the composition pane to Preformat
- Write your log message.
- Use the Insert->Text_File pulldown menu to insert the patch from a file. Do NOT use cut-and-paste to copy the patch, it'll likely corrupt the patch.
Thunderbird recipe #1
Yep, the odd part is not to disable html email. Then when composing a message, there is a drop-down box for a format selection. While the cursor is in the body area, change the format from default "Body text" to Preformat, and then copy-n-paste the patch.
- Before starting to write the email, do Edit->Preferences, Composition tab, change "Wrap plain text messages at __ characters" to 0
- Begin writing your email
- Start up an editor in which you can select the text, for example:
- # gvim patch.diff
- Edit->Select All
Switch back to the open Compose window, then Edit->Paste
Thunderbird recipe #2
If you have Enigmail configured, when sending the email, you might get a box asking if you want to change the line wrapping to 68 characters, so just say No if that happens.
Others have suggested using an external editor which will show up in the compose editor and allow to include the patch file inline. For example see http://mozex.mozdev.org
If everything fails ...
Git has some limited ability to process MIME attachments but as the word limited already expresses they're well, limited. If you really can't get your mailer to do inline uncorrupted patches you can try to attach them as a MIME attachment of text/plain type and ASCII encoding - that is 7-bit. Quoted-printable is pain ...
- http://mbligh.org/linuxdocs/Email/Clients/Thunderbird Martin Bligh's page about survival with Thunderbird
- Discussion on linux-kernel on patch submission with Thunderbird.