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.

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.

+

+

== Git ==

+

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 <tt>git format-patch</tt> and <tt>git send-email</tt>. It's going to format your emails the way recommended for submission in Documentation/ and make your life a lot easier.

== Evolution ==

== Evolution ==

Revision as of 01:02, 20 January 2012

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 <your@email.address> line

To faciliate the use of patchwork patches should always be cc'ed to the linux-mips@linux-mips.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.

Git

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.

Modern Thunderbird

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

Edit->Copy

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 ...