Difference between revisions of "Mailing-patches"

From LinuxMIPS
Jump to: navigation, search
m (The MIME problem)
m (Modern Thunderbird)
Line 31: Line 31:
  
 
== Modern Thunderbird ==
 
== Modern Thunderbird ==
* Set the formatting mode button just above the composition plane to ''Preformat''
+
* Set the formatting mode button just above the composition pane to ''Preformat''
 
* Write your log message.
 
* 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 lilely corrupt the patch.
+
* 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 receipe #1 ==
 
== Thunderbird receipe #1 ==

Revision as of 10:16, 5 June 2007

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

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.

Evolution

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

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 receipe #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 reformat, 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 receipe #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.

See also