From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: Why not "attach" patches?
Date: Tue, 15 Jan 2002 18:02:12 +0000 (UTC) [thread overview]
Message-ID: <a21qr4$36h$1@penguin.transmeta.com> (raw)
In-Reply-To: <005901c19dec$59a89e30$0201a8c0@HOMER>
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
next prev parent reply other threads:[~2002-01-15 18:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-15 17:44 Why not "attach" patches? Martin Eriksson
2002-01-15 17:47 ` David S. Miller
2002-01-15 17:52 ` Martin Dalecki
2002-01-15 18:04 ` Linus Torvalds
2002-01-15 18:50 ` Richard Gooch
2002-01-15 19:28 ` Alan Cox
2002-01-15 19:29 ` Davide Libenzi
2002-01-15 19:49 ` Nicolas Pitre
2002-01-15 22:09 ` Patrick Mochel
2002-01-15 22:16 ` Andreas Dilger
2002-01-16 0:11 ` Removing the whitespaces??? [Was: Re: Why not "attach" patches?] Henning P. Schmiedehausen
2002-01-16 4:16 ` Andreas Dilger
2002-01-17 8:56 ` Ravindra Jaju
2002-01-16 0:26 ` Stuart Young
2002-01-15 23:13 ` Why not "attach" patches? Urban Widmark
2002-01-15 23:51 ` Sebastian Benoit
2002-01-15 19:59 ` Jeff Garzik
2002-01-21 16:15 ` Daniel Phillips
2002-01-22 18:17 ` H. Peter Anvin
2002-01-24 6:59 ` Kai Henningsen
2002-01-16 11:46 ` Christoph Rohland
2002-01-16 17:22 ` Linus Torvalds
2002-01-15 17:57 ` Kent Borg
2002-01-15 19:38 ` Martin Eriksson
2002-01-15 19:48 ` Anton Altaparmakov
2002-01-15 23:34 ` Johan Kullstam
2002-01-15 18:02 ` Linus Torvalds [this message]
2002-01-15 18:39 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='a21qr4$36h$1@penguin.transmeta.com' \
--to=torvalds@transmeta.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox