Why not "attach" patches?

Why not "attach" patches?

[Martin Eriksson]

Why do many of you not _attach_ patches instead of merging them with the
mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
attached to the mail which can be saved in an appropriate directory. Also,
the whitespace is always retained that way.

OTOH I don't have very deep knowledge of "diff" and "patch", so maybe I have
missed something here...

 _____________________________________________________
|  Martin Eriksson <nitrax@giron.wox.org>
|  MSc CSE student, department of Computing Science
|  Umeå University, Sweden

- ABIT BP6(RU) - 2xCeleron 400 - 128MB/PC100/C2 Acer
- Maxtor 10/5400/U33 HPT P/M - Seagate 6/5400/U33 HPT S/M
- 2xDE-530TX - 1xTulip - Linux 2.4.17+ide+preempt

Re: Why not "attach" patches?

[David S. Miller]

   From: "Martin Eriksson" <nitrax@giron.wox.org>
   Date: Tue, 15 Jan 2002 18:44:58 +0100

   Why do many of you not _attach_ patches instead of merging them
   with the mail?

Because it allows people without mime decoders to read
the patch without feeding the email to external programs.

Re: Why not "attach" patches?

[Martin Dalecki]

Martin Eriksson wrote:

>Why do many of you not _attach_ patches instead of merging them with the
>mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
>attached to the mail which can be saved in an appropriate directory. Also,
>the whitespace is always retained that way.
>
>OTOH I don't have very deep knowledge of "diff" and "patch", so maybe I have
>missed something here...
>
Don't worry - nothign prevents proper attached patches from beeing 
applied - the FAQ is only a bit
zealous on this ;-)

Re: Why not "attach" patches?

[Linus Torvalds]

In article <3C446C77.3000806@evision-ventures.com>,
Martin Dalecki  <dalecki@evision-ventures.com> wrote:
>
>Don't worry - nothign prevents proper attached patches from beeing 
>applied - the FAQ is only a bit zealous on this ;-)

Wrong.

If I get a patch in an attachment (other than a "Text/PLAIN" type
attachment with no mangling and that pretty much all mail readers and
all tools will see as a normal body), I simply WILL NOT apply it unless
I have strong reason to. I usually wont even bother looking at it,
unless I expected something special from the sender.

Really. Don't send patches as attachments. 

		Linus

Re: Why not "attach" patches?

[Richard Gooch]

Linus Torvalds writes:
> In article <3C446C77.3000806@evision-ventures.com>,
> Martin Dalecki  <dalecki@evision-ventures.com> wrote:
> >
> >Don't worry - nothign prevents proper attached patches from beeing 
> >applied - the FAQ is only a bit zealous on this ;-)
> 
> Wrong.
> 
> If I get a patch in an attachment (other than a "Text/PLAIN" type
> attachment with no mangling and that pretty much all mail readers and
> all tools will see as a normal body), I simply WILL NOT apply it unless
> I have strong reason to. I usually wont even bother looking at it,
> unless I expected something special from the sender.
> 
> Really. Don't send patches as attachments. 

Thanks for providing material I can quote :-) I've updated the FAQ
entry on this, and also included your sage words:
http://www.tux.org/lkml/#s1-14

"So let it be written, so let it be done!" :-)

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: Why not "attach" patches?

[Alan Cox]

> all tools will see as a normal body), I simply WILL NOT apply it unless
> I have strong reason to. I usually wont even bother looking at it,
> unless I expected something special from the sender.
> 
> Really. Don't send patches as attachments. 

BTW: If you are sending me anything DO use attachments. Especially if you
use any of the following, which seem to have some versions that mangle 
inline diffs

	Lotus Notes
	Pine
	Kmail
	Mozilla
	Netscape
	MS Outlook

If you aren't sure if your mailer is ok then send yourself a block of text
that contains a line over 80 chars long, a line ending in space, and a line
with tabs in it

Check the tabs are still there, the space on the end of the line hasnt been
eaten (eg pine) and that the long line was not wrapped.

Alan

Re: Why not "attach" patches?

[Davide Libenzi]

On Tue, 15 Jan 2002, Alan Cox wrote:

> > all tools will see as a normal body), I simply WILL NOT apply it unless
> > I have strong reason to. I usually wont even bother looking at it,
> > unless I expected something special from the sender.
> >
> > Really. Don't send patches as attachments.
>
> BTW: If you are sending me anything DO use attachments. Especially if you
> use any of the following, which seem to have some versions that mangle
> inline diffs
>
> 	Lotus Notes
> 	Pine
> 	Kmail
> 	Mozilla
> 	Netscape
> 	MS Outlook

Pine works fine here if you use  ^R




- Davide

Re: Why not "attach" patches?

[Nicolas Pitre]

On Tue, 15 Jan 2002, Alan Cox wrote:

> BTW: If you are sending me anything DO use attachments. Especially if you
> use any of the following, which seem to have some versions that mangle 
> inline diffs
> 
> 	Lotus Notes
> 	Pine
> 	Kmail
> 	Mozilla
> 	Netscape
> 	MS Outlook

Pine always worked fine when patches are imported with ^R.


Nicolas

Re: Why not "attach" patches?

[Patrick Mochel]

On Tue, 15 Jan 2002, Nicolas Pitre wrote:

> On Tue, 15 Jan 2002, Alan Cox wrote:
>
> > BTW: If you are sending me anything DO use attachments. Especially if you
> > use any of the following, which seem to have some versions that mangle
> > inline diffs
> >
> > 	Lotus Notes
> > 	Pine
> > 	Kmail
> > 	Mozilla
> > 	Netscape
> > 	MS Outlook
>
> Pine always worked fine when patches are imported with ^R.

It doesn't at all. It silently removes extra white space at the end of
lines. It's been a "feature" since about 4.30 or so.

Does anyone recall exactly which version this changed in? Or, have any of
the vendors reversed this wart?

	-pat

Re: Why not "attach" patches?

[Andreas Dilger]

On Jan 15, 2002  14:09 -0800, Patrick Mochel wrote:
> On Tue, 15 Jan 2002, Nicolas Pitre wrote:
> > Pine always worked fine when patches are imported with ^R.
> 
> It doesn't at all. It silently removes extra white space at the end of
> lines. It's been a "feature" since about 4.30 or so.
> 
> Does anyone recall exactly which version this changed in? Or, have any of
> the vendors reversed this wart?

Well, it would be a feature if it knew enough to only remove whitespace
at the end of "+" lines in context diffs.  Then we wouldn't have 200kB
of useless whitespace in the kernel sources.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Removing the whitespaces??? [Was: Re: Why not "attach" patches?]

[Henning P. Schmiedehausen]

Andreas Dilger <adilger@turbolabs.com> writes:

>Well, it would be a feature if it knew enough to only remove whitespace
>at the end of "+" lines in context diffs.  Then we wouldn't have 200kB
>of useless whitespace in the kernel sources.

apply patches. Run this. Rinse. Repeat. :-)

--- cut ---

mkdir /usr/src/linux.noblanks

(
  cd /usr/src/linux
  find . -type d -exec mkdir -p /usr/src/linux.noblanks/{} \;
  for i in `find . -type f`; do
    perl -ne 's/[        ]+$//; print;' < ${i} > /usr/src/linux.noblanks/${i}
  done
)

diff -ur /usr/src/linux /usr/src/linux.noblanks | mail -s "blanks removed" torvalds@transmeta.com 

rm -rf /usr/src/linux.noblanks
--- cut ---

(This is a TAB and a space in the square brackets above. 
Don't use \s. Trust me.)

linux-2.2.20.tar.bz2:		15,751,285 bytes
linux-2.2.20-nbl.tar.bz2:       15,608,085 bytes

Patch Size (uncompressed):	17,815,166 bytes (yes this _is_ 17,4 MBytes)
           (compressed, bzip2):  3,322,456 bytes 

One mega-patch to shear off about 140 KBytes from the compressed (and
about 170 k from the unpacked (94488 vs. 94316 KBytes ) kernel source
would (while it may be the biggest single "reduce-size-of-kernel-tree
patch" in years :-) ) a little gross.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Removing the whitespaces??? [Was: Re: Why not "attach" patches?]

[Andreas Dilger]

On Jan 16, 2002  00:11 +0000, Henning P. Schmiedehausen wrote:
> Andreas Dilger <adilger@turbolabs.com> writes:
> >Well, it would be a feature if it knew enough to only remove whitespace
> >at the end of "+" lines in context diffs.  Then we wouldn't have 200kB
> >of useless whitespace in the kernel sources.
> 
> (This is a TAB and a space in the square brackets above. 
> Don't use \s. Trust me.)
> 
> linux-2.2.20.tar.bz2:		15,751,285 bytes
> linux-2.2.20-nbl.tar.bz2:       15,608,085 bytes
> 
> Patch Size (uncompressed):	17,815,166 bytes (yes this _is_ 17,4 MBytes)
>            (compressed, bzip2):  3,322,456 bytes 
> 
> One mega-patch to shear off about 140 KBytes from the compressed (and
> about 170 k from the unpacked (94488 vs. 94316 KBytes ) kernel source
> would (while it may be the biggest single "reduce-size-of-kernel-tree
> patch" in years :-) ) a little gross.

Oh, I'm not advocating sending in a huge patch _just_ to remove the
useless whitespace (which includes trailing spaces/tabs and [space][tab]
combinations), but it would be nice if someone is setting up a patchbot
to remove such whitespace in new or modified lines in a patch.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: Removing the whitespaces??? [Was: Re: Why not "attach" patches?]

[Ravindra Jaju]

On Wed, Jan 16, 2002 at 12:11:35AM +0000, Henning P. Schmiedehausen wrote:
> apply patches. Run this. Rinse. Repeat. :-)
> 
> --- cut ---
> 
> mkdir /usr/src/linux.noblanks
> 
> (
>   cd /usr/src/linux
>   find . -type d -exec mkdir -p /usr/src/linux.noblanks/{} \;
>   for i in `find . -type f`; do
>     perl -ne 's/[        ]+$//; print;' < ${i} > /usr/src/linux.noblanks/${i}
>   done
> )
> 
> diff -ur /usr/src/linux /usr/src/linux.noblanks | mail -s "blanks removed" torvalds@transmeta.com 
> 
> rm -rf /usr/src/linux.noblanks
> --- cut ---
> 
> (This is a TAB and a space in the square brackets above. 
> Don't use \s. Trust me.)
> 
> linux-2.2.20.tar.bz2:		15,751,285 bytes
> linux-2.2.20-nbl.tar.bz2:       15,608,085 bytes
> 
> Patch Size (uncompressed):	17,815,166 bytes (yes this _is_ 17,4 MBytes)
>            (compressed, bzip2):  3,322,456 bytes 
> 
> One mega-patch to shear off about 140 KBytes from the compressed (and
> about 170 k from the unpacked (94488 vs. 94316 KBytes ) kernel source
> would (while it may be the biggest single "reduce-size-of-kernel-tree
> patch" in years :-) ) a little gross.

Uh .. why not let Linus just run this program on *his* machine, and putting
up the patch again as a "program to be run"? ;-)

Saves Linus of the headache to check if there are any bugs in the patch
before applying ( and that too, with the funny label of "lossy something"
he's earned ... saves a lot of bandwidth! ;-) )

regards,
jaju

Re: Removing the whitespaces??? [Was: Re: Why not "attach" patches?]

[Stuart Young]

At 12:11 AM 16/01/02 +0000, Henning P. Schmiedehausen wrote:
>Patch Size (uncompressed):      17,815,166 bytes (yes this _is_ 17,4 MBytes)
>            (compressed, bzip2):  3,322,456 bytes
>
>One mega-patch to shear off about 140 KBytes from the compressed (and
>about 170 k from the unpacked (94488 vs. 94316 KBytes ) kernel source
>would (while it may be the biggest single "reduce-size-of-kernel-tree
>patch" in years :-) ) a little gross.

This 'sort' of thing would be a good idea for 2.5 IMHO (pref. asap), mainly 
to get it out of the way! It would probably be a good idea to do this on a 
tree just before it matures too (eg: when 2.5 migrates to 2.6/3.0/whatever).

The savings to other trees are probably not worth the effort involved for 
what we gain back (at the moment anyway).

You'll probably find that there are other things about that might save a 
few bytes here and there too (and at the same time might clean the code up 
a bit and make it more readable).


Stuart Young - sgy@amc.com.au
(aka Cefiar) - cefiar1@optushome.com.au

[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]

Re: Why not "attach" patches?

[Urban Widmark]

On Tue, 15 Jan 2002, Patrick Mochel wrote:

> It doesn't at all. It silently removes extra white space at the end of
> lines. It's been a "feature" since about 4.30 or so.

I am pretty sure that it works fine in RedHat's 4.33 version (or else
Linus would have dropped some of my patches ... er, more of my patches :).
But I haven't checked how that version differs from the original.

At the end is a simple ^R-ed file that works for me sending to myself.
But I don't think it is related to ^R ...   
(should be 3 spaces after that line)

If you postpone a message it has a silly idea to add an empty line at the
end. But that shouldn't break patches.

/Urban


no space
tab	
3 spaces   
no space

Re: Why not "attach" patches?

[Sebastian Benoit]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

Patrick Mochel(mochel@osdl.org)@2002.01.15 14:09:27 +0000:
> Does anyone recall exactly which version this changed in? Or, have any of
> the vendors reversed this wart?

https://www.redhat.com/support/errata/RHBA-2001-118.html
"The current releases of PINE 4.33 contain a whitespace mangling bug that is
fixed in this release."

/B.

-- 
Sebastian Benoit <benoit-lists@fb12.de>
GnuPG 0x5BA22F00 2001-07-31 2999 9839 6C9E E4BF B540  C44B 4EC4 E1BE 5BA2 2F00

Buy land. They've stopped making it. -- Mark Twain.

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: Why not "attach" patches?

[Jeff Garzik]

Some implementation-specific details people may find useful:

* For 4.xx versions of Netscape Mail, with standard mime types/prefs,
sending patches by MIME attachment results in a readable text/plain
message.

* The best way to mail patches is to pipe a header, patch description,
and contents to "/usr/sbin/sendmail -t" or some other MTA.  When I spam
Linus or Marcelo with patches, my process looks like this:

1) create outgoing patches
2) change e-mail header template to reflect current kernel version
3) put template and blank space at top of each patch
4) "vi *.patch", manually insert descriptions and CC list from
MAINTAINERS
5) review each patch and description once again :)
6) pipe *.patch individually through "/usr/sbin/sendmail -t"

Here is the mail header template I use.  Sendmail is smart and will
insert all other headers like message-id and date, since they are not
present.  When using another MTA, make sure yours does this too.

> [jgarzik@rum g]$ cat ~/info/mail.linus
> From: Jeff Garzik <jgarzik at mandrakesoft.com>
> BCC: jgarzik at mandrakesoft.com
> To: Linus Torvalds <torvalds at transmeta.com>
> CC: akpm at zip.com.au, davem at redhat.com
> Subject: PATCH 2.5.2.9: net drvr 
> 

As always, read Documentation/SubmittingPatches.  That's what it's there
for.

-- 
Jeff Garzik      | Alternate titles for LOTR:
Building 1024    | Fast Times at Uruk-Hai
MandrakeSoft     | The Took, the Elf, His Daughter and Her Lover
                 | Samwise Gamgee: International Hobbit of Mystery

Re: Why not "attach" patches?

[Daniel Phillips]

On January 15, 2002 08:28 pm, Alan Cox wrote:
> > all tools will see as a normal body), I simply WILL NOT apply it unless
> > I have strong reason to. I usually wont even bother looking at it,
> > unless I expected something special from the sender.
> > 
> > Really. Don't send patches as attachments. 
> 
> BTW: If you are sending me anything DO use attachments. Especially if you
> use any of the following, which seem to have some versions that mangle 
> inline diffs
> 
> 	Lotus Notes
> 	Pine
> 	Kmail
> [...]

Kmail's patch-mangling problems seem to be all gone in kmail 2.2+.  The only 
thing to be careful about is that word wrap should be off.  Since I forgot to 
turn it off a couple of times I now leave it permanently off and turn it on 
for individual mails as needed.

--
Daniel

Re: Why not "attach" patches?

[H. Peter Anvin]

Followup to:  <E16Sh69-0001iV-00@starship.berlin>
By author:    Daniel Phillips <phillips@bonn-fries.net>
In newsgroup: linux.dev.kernel
> 
> Kmail's patch-mangling problems seem to be all gone in kmail 2.2+.  The only 
> thing to be careful about is that word wrap should be off.  Since I
> forgot to
> turn it off a couple of times I now leave it permanently off and turn it on 
> for individual mails as needed.
> 

The common ground most people seems to be able to accept is:

a. Go ahead and make patches as attachments, if your MUA makes it easier;
b. Be bloody certain they're text/plain attachments.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: Why not "attach" patches?

[Kai Henningsen]

hpa@zytor.com (H. Peter Anvin)  wrote on 22.01.02 in <a2kac1$m0a$1@cesium.transmeta.com>:

> The common ground most people seems to be able to accept is:
>
> a. Go ahead and make patches as attachments, if your MUA makes it easier;
> b. Be bloody certain they're text/plain attachments.

... and that they have Content-Transfer-Encoding: 7bit or 8bit.

*Not* quoted-printable or base64.

Which means that you lose if the patch contains chars whose 8th bit is  
set, if any MTA between you and Linus/Alan/etc. doesn't like that. Which  
is not quite unlikely. (But most MUAs won't allow you to send something  
like that anyway.)

MfG Kai

Re: Why not "attach" patches?

[Christoph Rohland]

Hi Linus,

On Tue, 15 Jan 2002, Linus Torvalds wrote:
> Wrong.
> 
> If I get a patch in an attachment (other than a "Text/PLAIN" type
> attachment with no mangling and that pretty much all mail readers
> and all tools will see as a normal body),

So text/plain is ok for you? How about multiple cummulative patches
attached to one mail?

This is the case where I hate your strategy about attachments: You
want to have separate patches (what I clearly understand), but you do
not want attachments. That's fine most of the time as long as I send
it to you privately, but to public lists too many people miss the
important steps.

Greetings
		Christoph

Re: Why not "attach" patches?

[Linus Torvalds]

On Wed, 16 Jan 2002, Christoph Rohland wrote:
>
> On Tue, 15 Jan 2002, Linus Torvalds wrote:
> > Wrong.
> >
> > If I get a patch in an attachment (other than a "Text/PLAIN" type
> > attachment with no mangling and that pretty much all mail readers
> > and all tools will see as a normal body),
>
> So text/plain is ok for you?

text/plain is fine - it has all the properties a non-attachment has.

> How about multiple cummulative patches attached to one mail?

Absolutely not.  When I open my mail-client, and somebody has sent me 20
patches, I want to _see_ 20 mails. That way I can select from them, and
the mailreader clearly indicates which ones I've read, etc etc.

Multiple attachements have no advantages, and have several disadvantages.

> This is the case where I hate your strategy about attachments: You
> want to have separate patches (what I clearly understand), but you do
> not want attachments. That's fine most of the time as long as I send
> it to you privately, but to public lists too many people miss the
> important steps.

Sending large patches to public lists tends to be a mistake in the first
place. It just irritates the people who pay for bandwidth and do not want
to apply patches off the list.

		Linus

Re: Why not "attach" patches?

[Kent Borg]

On Tue, Jan 15, 2002 at 06:44:58PM +0100, Martin Eriksson wrote:
> Why do many of you not _attach_ patches instead of merging them with the
> mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
> attached to the mail which can be saved in an appropriate directory. Also,
> the whitespace is always retained that way.

It is nice to have the patch to look at when looking at the mail, and
it is nice to have the mail to look at when looking at the patch.

One of the features of patch is that you can save the whole patch
e-mail to a file and use it directly; patch is willing to skip over
all the e-mail headers and regular looking text until it sees
something that looks like a patch.  Handy, huh?


-kb

Re: Why not "attach" patches?

[Martin Eriksson]

----- Original Message -----
From: "Kent Borg" <kentborg@borg.org>
To: "Martin Eriksson" <nitrax@giron.wox.org>
Cc: <linux-kernel@vger.kernel.org>
Sent: Tuesday, January 15, 2002 6:57 PM
Subject: Re: Why not "attach" patches?


> On Tue, Jan 15, 2002 at 06:44:58PM +0100, Martin Eriksson wrote:
> > Why do many of you not _attach_ patches instead of merging them with the
> > mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
> > attached to the mail which can be saved in an appropriate directory.
Also,
> > the whitespace is always retained that way.
>
> It is nice to have the patch to look at when looking at the mail, and
> it is nice to have the mail to look at when looking at the patch.
>
> One of the features of patch is that you can save the whole patch
> e-mail to a file and use it directly; patch is willing to skip over
> all the e-mail headers and regular looking text until it sees
> something that looks like a patch.  Handy, huh?

Aaah.. DOH! That was just what was lurking in the back of my head, but the
thinking part of the brain didn't quite grasp it. Of course "patch" will
skip "no-patch" text instead of crapping out. Hell, if I'd designed the
"patch" program that behaviour would have been one of the first things to
implement.

Sorry for the LKML spam then =) but ain't it nice with one of these
"easy-to-answer" mails from time to time...?

/Martin Eriksson

PS. I really hate OE. Anyone care to recommend THE Windoze Mail+News reader
program, with EXTREME filtering capabilities AND not looking like crap?

Re: Why not "attach" patches?

[Anton Altaparmakov]

Slightly off topic to lkml so replies off list please...

On Tue, 15 Jan 2002, Martin Eriksson wrote:
> PS. I really hate OE. Anyone care to recommend THE Windoze Mail+News reader
> program, with EXTREME filtering capabilities AND not looking like crap?

I use two:

Eudora 5 for mail
Forte Free Agent for news

IMO the best GUI clients full stop.

For sending inlined patches I use elm (on Solaris) which while basic gets
the job done guaranteed without messing up the precious white space...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: Why not "attach" patches?

[Johan Kullstam]

"Martin Eriksson" <nitrax@giron.wox.org> writes:

> ----- Original Message -----
> From: "Kent Borg" <kentborg@borg.org>
> To: "Martin Eriksson" <nitrax@giron.wox.org>
> Cc: <linux-kernel@vger.kernel.org>
> Sent: Tuesday, January 15, 2002 6:57 PM
> Subject: Re: Why not "attach" patches?
> 
> 
> > On Tue, Jan 15, 2002 at 06:44:58PM +0100, Martin Eriksson wrote:
> > > Why do many of you not _attach_ patches instead of merging them with the
> > > mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
> > > attached to the mail which can be saved in an appropriate directory.
> Also,
> > > the whitespace is always retained that way.
> >
> > It is nice to have the patch to look at when looking at the mail, and
> > it is nice to have the mail to look at when looking at the patch.
> >
> > One of the features of patch is that you can save the whole patch
> > e-mail to a file and use it directly; patch is willing to skip over
> > all the e-mail headers and regular looking text until it sees
> > something that looks like a patch.  Handy, huh?
> 
> Aaah.. DOH! That was just what was lurking in the back of my head, but the
> thinking part of the brain didn't quite grasp it. Of course "patch" will
> skip "no-patch" text instead of crapping out. Hell, if I'd designed the
> "patch" program that behaviour would have been one of the first things to
> implement.
> 
> Sorry for the LKML spam then =) but ain't it nice with one of these
> "easy-to-answer" mails from time to time...?
> 
> /Martin Eriksson
> 
> PS. I really hate OE. Anyone care to recommend THE Windoze Mail+News reader
> program, with EXTREME filtering capabilities AND not looking like
> crap?

dunno if you feel it looks like crap or not, but i recommend
gnus/emacs.  it works great on both windows and linux.  it can split
mail into buckets/folders.  it has better than filtering, it has
SCORING.

i am not sure what to do about the ubiquitous sendmail/mailbox ^From
braindamage though.  qmail using maildir doesn't suffer from it.

-- 
J o h a n  K u l l s t a m
[kullstam@mediaone.net]

Re: Why not "attach" patches?

[Linus Torvalds]

In article <005901c19dec$59a89e30$0201a8c0@HOMER>,
Martin Eriksson <nitrax@giron.wox.org> wrote:
>Why do many of you not _attach_ patches instead of merging them with the
>mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
>attached to the mail which can be saved in an appropriate directory. Also,
>the whitespace is always retained that way.

Attached patches are _horrible_ once you have many patches that you want
to maintain in a sane way and apply in one go.

In particular, with in-line text patches, I can:

 - see the patch easily when reading email, without the need to do
   anything special to inspect the attachment, regardless of what email
   client I happen to use.

 - keep emails as emails, and save them to folders etc, without
   losing any information of where the patch came from, while at the
   same time the folders are _also_ the patch and work with standard
   tools like "diffstat".

 - easily just "reply" to the person, and quote the part of the patch
   I have problems with.

 - save all the emails I want to apply in one single email folder
   ("doit"), and do a simple

	patch -p1 < ~/doit

   to apply all of them at the same time.

Note that NONE of these are practical with attachments.

In short: if your mailer eats whitespace or causes similar corruption,
just FIX THE MAILER.  There is no excuse for a mailer that corrupts the
mail. 

And while attachments may _appear_ convenient, they most definitely are
not.  They require special care and cannot be batched or edited with
normal tools. 

That may not matter if you just have one or two patches a week to worry
about, but trust me - attachments are crap. Use them for binary data
that cannot be edited or combined, _not_ for stuff you expect to be able
to actually change and extract pieces of with regular tools.

		Linus

Re: Why not "attach" patches?

[Andi Kleen]

"Martin Eriksson" <nitrax@giron.wox.org> writes:

> Why do many of you not _attach_ patches instead of merging them with the
> mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
> attached to the mail which can be saved in an appropriate directory. Also,
> the whitespace is always retained that way.
> 
> OTOH I don't have very deep knowledge of "diff" and "patch", so maybe I have
> missed something here...

Patches are often saved and applied later. In this case it is useful to have
the context of the mail message it was contained in around in the same 
file, so that you later actually know what you apply if you happen to 
not memorize it completely. Patch will ignore the mail part so it can be 
still applied directly.

With saved attachments you usually just a patch and no description, or 
it requires extra effort to save the description too. 

-Andi