update SubmittingPatches to clarify attachment policy
RFC PATCH 1/1 update SubmittingPatches to clarify attachment policy
I think the general opinion of posting patches as attachments has changed over the last few years. Mailers have been getting a lot better at handling them, even quoting non-message-body plain/text attachments in replies.
Plus, a plain/text attachment message saved to a file can go into 'patch' the same way that an inline one can.
---
memhotplug-dave/Documentation/SubmittingPatches | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-)
diff -L Documentation/Submitting -puN /dev/null /dev/null
Documentation/SubmittingPatches renamed from Documentation/SubmittingPatches~submitting-patches +9 -2
@@ -181,17 +181,24 @@ patches. Trivial patches must qualify fo -6) No MIME, no links, no compression, no attachments. Just plain text. +6) No MIME, no links, no compression. 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. -For this reason, all patches should be submitting e-mail "inline". +For this reason, the preferred way of submitting patches in e-mail is +"inline", in the same part of the message with everything else. WARNING: Be wary of your editor's word-wrap corrupting your patch, if you choose to cut-n-paste your patch. +Many maintainers will now accept patches submitted to them as +text/plain attachments. Many mailers quote these attachements in the +same way that they do for inline patches. But, some maintainers still +prefer inlines and they are certainly the safest bet. In any case, +never attach more than one patch to a single e-mail. + Do not attach the patch as a MIME attachment, compressed or not. Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your
_
Quoted 5 lines · Dave Hansen
I think the general opinion of posting patches as attachments has changed over the last few years. Mailers have been getting a lot better at handling them, even quoting non-message-body plain/text attachments in replies.
What, Linus updated his pine?????
Signature · 1 line
Dmitry
Quoted 2 lines · Dave Hansen
-6) No MIME, no links, no compression, no attachments. Just plain text. +6) No MIME, no links, no compression. Just plain text.
Logically buggy. You can't have an attachment without the MIME markup that *says* it's an attachment. I think what you meant was "No Content-Type-Encoding":
i.e. 'none' is acceptable, but 'quoted-printable' (which causes all the spurious =20 and =3D you sometimes see) and 'base64' (uuencode on steroids) aren't....
Quoted 10 lines · On Wed, 2005-05-04 at 13:16 -0400, [email protected] wrote:
Quoted 2 lines · Dave Hansen
-6) No MIME, no links, no compression, no attachments. Just plain text. +6) No MIME, no links, no compression. Just plain text.
Logically buggy. You can't have an attachment without the MIME markup that *says* it's an attachment. I think what you meant was "No Content-Type-Encoding":
i.e. 'none' is acceptable, but 'quoted-printable' (which causes all the spurious =20 and =3D you sometimes see) and 'base64' (uuencode on steroids) aren't....
Thanks for pointing out my flawed logic. I wasn't quite sure what was MIME and what wasn't. How about the attached patch, instead?
-- Dave
I think the general opinion of posting patches as attachments has changed over the last few years. Mailers have been getting a lot better at handling them, even quoting non-message-body plain/text attachments in replies.
Plus, a plain/text attachment message saved to a file can go into 'patch' the same way that an inline one can.
---
memhotplug-dave/Documentation/SubmittingPatches | 20 ++++++++++++++------ 1 files changed, 14 insertions(+), 6 deletions(-)
diff -L Documentation/Submitting -puN /dev/null /dev/null
Documentation/SubmittingPatches renamed from Documentation/SubmittingPatches~submitting-patches +14 -6
@@ -181,25 +181,33 @@ patches. Trivial patches must qualify fo -6) No MIME, no links, no compression, no attachments. Just plain text. +6) No links, no compressed 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. -For this reason, all patches should be submitting e-mail "inline". +For this reason, the preferred way of submitting patches in e-mail is +"inline", in the same part of the message with everything else. WARNING: Be wary of your editor's word-wrap corrupting your patch, if you choose to cut-n-paste your patch. -Do not attach the patch as a MIME attachment, compressed or not. +Many maintainers will now accept patches submitted to them as +text/plain attachments. Many mailers quote these attachements in the +same way that they do for inline patches. But, some maintainers still +prefer inlines and they are certainly the safest bet. In any case, +never attach more than one patch to a single e-mail. + Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your -code. A MIME attachment also takes Linus a bit more time to process, -decreasing the likelihood of your MIME-attached change being accepted. +code. If you must use an attachment, verify that it has no +Content-Type-Encoding. A MIME attachment also takes Linus a bit more +time to process, decreasing the likelihood of your MIME-attached +change being accepted. Exception: If your mailer is mangling patches then someone may ask -you to re-send them using MIME. +you to re-send them compressed or using other MIME encodings.
_
Quoted 6 lines · * Dave Hansen ([email protected]) wrote:
Quoted 5 lines · On Wed, 2005-05-04 at 13:16 -0400, [email protected] wrote:
Quoted 2 lines · Dave Hansen
-6) No MIME, no links, no compression, no attachments. Just plain text. +6) No MIME, no links, no compression. Just plain text.
Quoted 8 lines
Quoted 5 lines
Logically buggy. You can't have an attachment without the MIME markup that *says* it's an attachment. I think what you meant was "No Content-Type-Encoding":
i.e. 'none' is acceptable, but 'quoted-printable' (which causes all the spurious =20 and =3D you sometimes see) and 'base64' (uuencode on steroids) aren't....Thanks for pointing out my flawed logic. I wasn't quite sure what was MIME and what wasn't. How about the attached patch, instead?
I agree that things are better. But, ironically, this patch is a case in point. It's attached as text/x-patch and makes replying to and commenting on patch inline more laborious. Perhaps it should be clear, text/plain tends to work (and is better than inline whitespace damaged patches). Andrew's "The Perfect Patch" has some text you could lift.
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
thanks,
-chris
Quoted 3 lines · Chris Wright
I agree that things are better. But, ironically, this patch is a case in point. It's attached as text/x-patch and makes replying to and commenting on patch inline more laborious.
Well, crap.
I've sent an awful lot of patches that way, and never had a negative reply from a maintainer or a patch commenter.
As an aside: is there a proper way to do patch text/plain attachments from Evolution? Maybe we need a quick tutorial on what the best way to send patches is with several popular mailers.
-- Dave
ons 2005-05-04 klockan 11:14 -0700 skrev Dave Hansen:
Quoted 5 lines · Chris Wright
Quoted 3 lines
I agree that things are better. But, ironically, this patch is a case in point. It's attached as text/x-patch and makes replying to and commenting on patch inline more laborious.
Quoted 9 lines
Well, crap.
I've sent an awful lot of patches that way, and never had a negative reply from a maintainer or a patch commenter.
As an aside: is there a proper way to do patch text/plain attachments from Evolution? Maybe we need a quick tutorial on what the best way to send patches is with several popular mailers.
In evolution I just do new mail => insert => text file and change the mail to preformat instead of normal formatting. I'm sure there are settings somewhere to make this default but I don't send enough patches (yet) to bother, the output works anyway (old patch shown below):
arch/x86_64/kernel/head64.c +0 -3
@@ -93,9 +93,6 @@#ifdef CONFIG_SMP cpu_set (0 , cpu_online_map);#endif -/* default console: */ -if (!strstr (saved_command_line,"console=" )) -strcat (saved_command_line," console=tty0" ); s =strstr (saved_command_line,"earlyprintk=" );if (s !=NULL )setup_early_printk (s);
Quoted 3 lines · Dave Hansen
As an aside: is there a proper way to do patch text/plain attachments from Evolution? Maybe we need a quick tutorial on what the best way to send patches is with several popular mailers.
I feel this is needed, yes. Don't forget to include Microsoft Outlook :)
Jeff
Quoted 6 lines · Dave Hansen
Quoted 5 lines · On Wed, 2005-05-04 at 13:16 -0400, [email protected] wrote:
Quoted 2 lines · Dave Hansen
-6) No MIME, no links, no compression, no attachments. Just plain text. +6) No MIME, no links, no compression. Just plain text.
Quoted 8 lines
Quoted 5 lines
Logically buggy. You can't have an attachment without the MIME markup that *says* it's an attachment. I think what you meant was "No Content-Type-Encoding":
i.e. 'none' is acceptable, but 'quoted-printable' (which causes all the spurious =20 and =3D you sometimes see) and 'base64' (uuencode on steroids) aren't....Thanks for pointing out my flawed logic. I wasn't quite sure what was MIME and what wasn't. How about the attached patch, instead?
I don't like it, but that is only because your mailer sends them as test/x-patch and my mailer cannot quote the patch in reply :)
Thanks
Dipankar
Documentation/SubmittingPatches patches. Trivial patches must qualify fo
Quoted 4 lines · Dave Hansen
Documentation/SubmittingPatches renamed from Documentation/SubmittingPatches~submitting-patches +4
-0+Many maintainers will now accept patches submitted to them as +text/plain attachments. Many mailers quote these attachements in the +same way that they do for inline patches. But, some maintainers still +prefer inlines and they are certainly the safest bet.
There is MIME "Content-Disposition: inline".
Personally I think it's at least as good as plain text - it's MIME attachment (you can extract automatically, you have well-defined patch boundaries, original file name etc.) _and_ mail readers are supposed to (and do) display such attachments as normal message parts.
The message is readable with MIME-unaware readers (scripts etc.) as well.
Such attachment (raw message data) looks like:
From: xxx@yyy
To: lkml
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
--=-=-=
Normal message text etc.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline; filename=xxx.patch
--- linux-2.6/xxx.c 25 May 2003 22:13:37
+++ linux-2.6/xxx.c 25 May 2003 22:13:38
the rest of patch text
--=-=-=--
Quoted 1 line
+code. If you must use an attachment,
Nearly no one "must" use attachments. I can only think of people using broken mail servers ("corporate servers").
Quoted 2 lines
verify that it has no
+Content-Type-Encoding.
Content-Transfer-Encoding.
I'd say "verify that it's binary-encoded - quoted-printable and base64 encodings are not permitted".
I.e., it's perfectly fine to specify "Content-Transfer-Encoding: 7bit" (or "8bit" or possibly "binary", though I don't exactly know the difference between "8bit" and "binary").
Documentation/SubmittingPatches patches. Trivial patches must qualify fo · line 207
Quoted 3 lines
A MIME attachment also takes Linus a bit more
Documentation/SubmittingPatches renamed from Documentation/SubmittingPatches~submitting-patches +2
-0+time to process, decreasing the likelihood of your MIME-attached +change being accepted.
I don't think so. Badly formatted MIME attachments, sure. I'd be surprised if Linus applies them at all.
Documentation/SubmittingPatches patches. Trivial patches must qualify fo · line 210
Quoted 3 lines
Exception: If your mailer is mangling patches then someone may ask
Documentation/SubmittingPatches renamed from Documentation/SubmittingPatches~submitting-patches +1
-1-you to re-send them using MIME. +you to re-send them compressed or using other MIME encodings.
Rather: "... someone may ask you to re-send them as properly encoded MIME attachments".
In fact I'd encourage using binary-encoded inlined MIME attachments at all times, with non-MIME 7bit or 8bit plain text being accepted as secondary format.
Signature · 1 line
Krzysztof Halasa
Quoted 10 lines · On Wed, 04 May 2005 20:52:45 +0200 Krzysztof Halasa <[email protected]> wrote:
There is MIME "Content-Disposition: inline".
Personally I think it's at least as good as plain text - it's MIME attachment (you can extract automatically, you have well-defined patch boundaries, original file name etc.) _and_ mail readers are supposed to (and do) display such attachments as normal message parts.The message is readable with MIME-unaware readers (scripts etc.) as well.
Such attachment (raw message data) looks like:
[snip]
Quoted 30 lines
Quoted 5 lines
+code. If you must use an attachment,
verify that it has no
+Content-Type-Encoding.Content-Transfer-Encoding.
I'd say "verify that it's binary-encoded - quoted-printable and base64 encodings are not permitted".
I.e., it's perfectly fine to specify "Content-Transfer-Encoding: 7bit" (or "8bit" or possibly "binary", though I don't exactly know the difference between "8bit" and "binary").
Documentation/SubmittingPatches patches. Trivial patches must qualify fo · line 207
Quoted 3 lines
A MIME attachment also takes Linus a bit more
Documentation/SubmittingPatches renamed from Documentation/SubmittingPatches~submitting-patches +2
-0+time to process, decreasing the likelihood of your MIME-attached +change being accepted.I don't think so. Badly formatted MIME attachments, sure. I'd be surprised if Linus applies them at all.
Documentation/SubmittingPatches patches. Trivial patches must qualify fo · line 210
Quoted 3 lines
Exception: If your mailer is mangling patches then someone may ask
Documentation/SubmittingPatches renamed from Documentation/SubmittingPatches~submitting-patches +1
-1-you to re-send them using MIME. +you to re-send them compressed or using other MIME encodings.Rather: "... someone may ask you to re-send them as properly encoded MIME attachments".
Quoted 3 lines
In fact I'd encourage using binary-encoded inlined MIME attachments at all times, with non-MIME 7bit or 8bit plain text being accepted as secondary format.
A couple of days ago, Matt Mackall described/proposed a tool to check new patches for acceptable content and format:
http://www.selenic.com/pipermail/kernel-mentors/2005-May/000072.html
I'm attaching a rudimentary version of such a tool (check-patch.pl). It does not attempt to check for line wrapping or lines that are
Quoted 1 line
80 characters.
It dislikes patches that contain attachments that are base64, quoted-printable, or binary (e.g.).
People can run this script locally, but ideally We (royal) will have an email address for it so that people can use it to check if their mail interface munges the patch for them... :( and can try again until it doesn't.
Yeah, it's not perfect and it's a bit verbose.
Patches accepted (or even complete rewrites :).
---
~Randy
Quoted 7 lines · Randy.Dunlap
A couple of days ago, Matt Mackall described/proposed a tool to check new patches for acceptable content and format:
http://www.selenic.com/pipermail/kernel-mentors/2005-May/000072.htmlI'm attaching a rudimentary version of such a tool (check-patch.pl). It does not attempt to check for line wrapping or lines that are
Quoted 1 line
80 characters.
I made a simpler (it's only regexes :-) ) and uglier version, which does check for line wrapping.
I probably won't have too much time to work on it, so feel free to do whatever you want with it.
Quoted 7 lines
It dislikes patches that contain attachments that are base64, quoted-printable, or binary (e.g.).
People can run this script locally, but ideally We (royal) will have an email address for it so that people can use it to check if their mail interface munges the patch for them... :( and can try again until it doesn't.
I put mine on [email protected] ... don't abuse it too much, it's just an old pentium on adsl there :-)
Domen
Quoted 5 lines · Dave Hansen
I think the general opinion of posting patches as attachments has changed over the last few years. Mailers have been getting a lot better at handling them, even quoting non-message-body plain/text attachments in replies.
There is also the problem of things like gmail/yahoo where you can't control the word wrapping. The only way to submit patches from those services is as an plain text attachment. If you try to submit then in-line and they wrap wrong you will collect a lot of hate mail from Andrew.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 7 lines · Jon Smirl
Quoted 5 lines · Dave Hansen
I think the general opinion of posting patches as attachments has changed over the last few years. Mailers have been getting a lot better at handling them, even quoting non-message-body plain/text attachments in replies.
Quoted 5 lines
There is also the problem of things like gmail/yahoo where you can't control the word wrapping. The only way to submit patches from those services is as an plain text attachment. If you try to submit then in-line and they wrap wrong you will collect a lot of hate mail from Andrew.
Well, why should someone use a broken mail service at all?
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 14 lines · Jan-Benedict Glaw
Quoted 7 lines · Jon Smirl
Quoted 5 lines · Dave Hansen
I think the general opinion of posting patches as attachments has changed over the last few years. Mailers have been getting a lot better at handling them, even quoting non-message-body plain/text attachments in replies.
Quoted 5 lines
There is also the problem of things like gmail/yahoo where you can't control the word wrapping. The only way to submit patches from those services is as an plain text attachment. If you try to submit then in-line and they wrap wrong you will collect a lot of hate mail from Andrew.
Quoted 3 lines
Well, why should someone use a broken mail service at all?
MfG, JBG
Because the net Nazis make often make it the only way to send/receive mail in a domain. There is nothing coming or going here that doesn't go through a M$ mail-killer that even saves every thread of evidence.
For instance, there is no signature on this file. I'll bet that by the time you read it, there is one.
Quoted 7 lines · Richard B. Johnson
Quoted 1 line · Jan-Benedict Glaw
Well, why should someone use a broken mail service at all?
Because the net Nazis make often make it the only way to send/receive mail in a domain. There is nothing coming or going here that doesn't go through a M$ mail-killer that even saves every thread of evidence.
No way to send emails with a locally installed email client? There are so many, even for Windows. ...and I guess quite some of those can be configured to produce real emails, not only bullshit...
Quoted 2 lines
For instance, there is no signature on this file. I'll bet that by the time you read it, there is one.
Nope, your email was fine. No extra crap like copyright/property disclaimers and the like.
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 5 lines · Jan-Benedict Glaw
Quoted 4 lines · Richard B. Johnson
Quoted 1 line · Jan-Benedict Glaw
Well, why should someone use a broken mail service at all?
Quoted 7 lines
Quoted 3 lines
Because the net Nazis make often make it the only way to send/receive mail in a domain. There is nothing coming or going here that doesn't go through a M$ mail-killer that even saves every thread of evidence.
No way to send emails with a locally installed email client? There are so many, even for Windows. ...and I guess quite some of those can be configured to produce real emails, not only bullshit...
Hell no. You think any sane admin is going to let every workstation on the corporate network make outgoing port 25 connections to wherever they want?
Lee
Quoted 9 lines · Lee Revell
Quoted 3 lines · Jan-Benedict Glaw
No way to send emails with a locally installed email client? There are so many, even for Windows. ...and I guess quite some of those can be configured to produce real emails, not only bullshit...
Hell no. You think any sane admin is going to let every workstation on the corporate network make outgoing port 25 connections to wherever they want?
Well, in most companies (at least those that have a central internet connection), people *can* send emails in one way or the other... Really, I don't see the problem. If you cannot send emails from your company, hell, then do it at home or from an internet café.
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Hi,
Quoted 7 lines · Jon Smirl
Quoted 5 lines · Dave Hansen
I think the general opinion of posting patches as attachments has changed over the last few years. Mailers have been getting a lot better at handling them, even quoting non-message-body plain/text attachments in replies.
Quoted 5 lines
There is also the problem of things like gmail/yahoo where you can't control the word wrapping. The only way to submit patches from those services is as an plain text attachment. If you try to submit then in-line and they wrap wrong you will collect a lot of hate mail from Andrew.
Well, IMHO, if your mailer does not handle patches correctly, you can try to include your patch in the message body and say something like "sorry, my mailer messes up with patches so I'm attaching it too", _and_ attach it ...
Greets,
Rafael
Signature · 3 lines
- Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland"
Quoted 5 lines · Dave Hansen
I think the general opinion of posting patches as attachments has changed over the last few years. Mailers have been getting a lot better at handling them, even quoting non-message-body plain/text attachments in replies.
Personally, I hate seeing patches as attachments. No offense, but I hope this patch is ignored.
John
Signature · 2 lines
John W. Linville [email protected]
Quoted 2 lines · Dave Hansen
Plus, a plain/text attachment message saved to a file can go into 'patch' the same way that an inline one can.
The problem is replying to an attachment. The reason why having the patch in the main mail body is good is that it gets quoted by the email software and you can easily reply to individual parts of the patch.
Signature · 3 lines
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Quoted 8 lines · Rik van Riel
Quoted 2 lines · Dave Hansen
Plus, a plain/text attachment message saved to a file can go into 'patch' the same way that an inline one can.
The problem is replying to an attachment. The reason why having the patch in the main mail body is good is that it gets quoted by the email software and you can easily reply to individual parts of the patch.
Indeed. `perfect' patches as attachments are fine. Maybe that's why some people testified they never got complaints about their attached patches :-)
But as soon as you have to point out some comments, replying takes a lot more time (save attachment, load it in editor, prepend every line with `> ', ...), and may lead to maintainer burn-out.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 4 lines · Rik van Riel
The problem is replying to an attachment. The reason why having the patch in the main mail body is good is that it gets quoted by the email software and you can easily reply to individual parts of the patch.
If the attachment is "disposition=inline", does the problem still exist?
Signature · 1 line
Krzysztof Halasa
Quoted 10 lines · Krzysztof Halasa
Quoted 4 lines · Rik van Riel
The problem is replying to an attachment. The reason why having the patch in the main mail body is good is that it gets quoted by the email software and you can easily reply to individual parts of the patch.
If the attachment is "disposition=inline", does the problem still exist?
I've just checked this with Thunderbird (which is the mail client I use).
It not only sets the disposition=inline by default when attaching patches, it also places the patch inline when replying to it, allowing the user to write between the text of the patch as if it were part of the email text.
However if we Copy+Paste the patch into the mail it gets line wrapped / white space mangled.
So at least for Thunderbird users it would be better to use attached patches with "Content-Disposition: inline".
Signature · 4 lines
Paulo Marques - www.grupopie.com All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke (1729 - 1797)
Quoted 12 lines · Paulo Marques
Quoted 10 lines · Krzysztof Halasa
Quoted 4 lines · Rik van Riel
The problem is replying to an attachment. The reason why having the patch in the main mail body is good is that it gets quoted by the email software and you can easily reply to individual parts of the patch.
Quoted 8 lines
Quoted 1 line
If the attachment is "disposition=inline", does the problem still exist?
I've just checked this with Thunderbird (which is the mail client I use).
It not only sets the disposition=inline by default when attaching patches, it also places the patch inline when replying to it, allowing the user to write between the text of the patch as if it were part of the email text.
However if we Copy+Paste the patch into the mail it gets line wrapped / white space mangled.
That depends on where you are Copy+Pasting from. Granted, Copy+Paste from a variety of sources is a nightmare. But, Copy+Paste from Tbird to Tbird seems to actually work.
Quoted 3 lines
So at least for Thunderbird users it would be better to use attached patches with "Content-Disposition: inline".
Here is a trick you can play with Thunderbird to get inlined patches:
1) Mail the patch to yourself as an attachment.
2) Read the mail you just got, copy and paste the patch to your new message.
This method preserves the tabs/whitespace. Of course, you have to set the wordwrap settings appropriately. It works for me.
Steven
Quoted 14 lines · Steven Cole
Quoted 3 lines · Paulo Marques
However if we Copy+Paste the patch into the mail it gets line wrapped / white space mangled.
That depends on where you are Copy+Pasting from. Granted, Copy+Paste from a variety of sources is a nightmare. But, Copy+Paste from Tbird to Tbird seems to actually work.
Quoted 4 lines
So at least for Thunderbird users it would be better to use attached patches with "Content-Disposition: inline".
Quoted 7 lines
Here is a trick you can play with Thunderbird to get inlined patches:
1) Mail the patch to yourself as an attachment.
2) Read the mail you just got, copy and paste the patch to your new message.This method preserves the tabs/whitespace. Of course, you have to set the wordwrap settings appropriately. It works for me.
Personally, I don't understand people who can hack the kernel but complain about bugs in their mail client.
Lee
Quoted 2 lines · Lee Revell
Personally, I don't understand people who can hack the kernel but complain about bugs in their mail client.
In some cases, the kernel is less lines of better-understood code.. :)
Current Fedora-devel tree:
-rw-rw-r-- 1 33474781 Mar 31 00:09 thunderbird-1.0.2-1.src.rpm -rw-r--r-- 1 42109198 May 4 18:52 kernel-2.6.11-1.1286_FC4.src.rpm
(And the kernel doesn't drag in Xorg and Gnome libraries on top of that like thunderbird does)....