Why not "attach" patches?

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 <[email protected]>
|  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

From: "Martin Eriksson" <[email protected]>
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.

Don't worry - nothign prevents proper attached patches from beeing applied - the FAQ is only a bit zealous on this ;-)

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

In article <005901c19dec$59a89e30$0201a8c0@HOMER>,

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

In article <[email protected]>,

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

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: [email protected]
Current:   [email protected]

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

Pine works fine here if you use ^R

- Davide

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

Nicolas

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

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

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/

Patrick Mochel([email protected])@2002.01.15 14:09:27 +0000:

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 <[email protected]>
GnuPG 0x5BA22F00 2001-07-31 2999 9839 6C9E E4BF B540  C44B 4EC4 E1BE 5BA2 2F00

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

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" [email protected]

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     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

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 - [email protected]
(aka Cefiar) - [email protected]

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

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/

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

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.

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

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

Followup to:  <[email protected]>
By author:    Daniel Phillips <[email protected]>
In newsgroup: linux.dev.kernel

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

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

[email protected] (H. Peter Anvin) wrote on 22.01.02 in <[email protected]>:

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

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

----- Original Message -----
From: "Kent Borg" <[email protected]>
To: "Martin Eriksson" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, January 15, 2002 6:57 PM
Subject: Re: Why not "attach" patches?

Also,

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?

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

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/

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
[[email protected]]

Hi Linus,

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

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

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.

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