From: Linus Torvalds <torvalds@osdl.org>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [EGIT PATCH] Convert author and comment on demand.
Date: Sun, 3 Dec 2006 10:08:02 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0612030955320.3476@woody.osdl.org> (raw)
In-Reply-To: <ekug7o$35c$1@sea.gmane.org>
On Sun, 3 Dec 2006, Jakub Narebski wrote:
>
> It is easier to comment on patch if it is embedded in the mail, and not
> in attachement.
This is why I _hate_ patches in attachments.
Sure, I can make my mail reader show the attachments. But when I "reply",
I want the patch to be indented with the regular "> " thing and visible in
the reply, so that I can say "I like the patch in general, but <this> part
of it is seriously broken".
And yes, the personal mailreader I have has a "include attachements in
reply" mode. But I don't generally want to include attachments in any
reply, I just want it for _patches_.
[ Side ntoe: besides, many people send broken attachments that aren't
marked as text, but as 8-bit binary data or something, even if it's a
text-patch - so "attachement problems" are almost as common as the
non-attachement "line wrap" or whitespace problems are - people who
think that attachments automatically means that the thing is correct are
just deluding themselves.
The fact is, you can get attachments wrong exactly the same way you get
linewrapping wrong. It's just that the pure binary data is likely to
always make it through correctly with an attachment, but if it gets
marked as a binary MIME-type, that doesn't much help, because while the
data is there, it's still going to act the wrong way for any
_discussion_ about it. ]
In other words: there are lots of things that make sense as true
attachments. It's just that "patch" is not one of them.
Patches, unlike for example full files or tar-balls, by their very design
are (a) text and (b) something where the whole _point_ is discussion and
quoting about them. If we didn't want to discuss the patch contents, we
wouldn't send them as patches in the first place, they'd be git-to-git
transfers.
So this all boils down to one thing:
PATCHES ARE NOT SEPARATE FILES TO BE ATTACHED TO AN EMAIL.
Patches are to be considered part of the discussion, not separate. And
thus they should be in the main body of the email, exactly so that people
(regardless of mailer settings and details like that) will automatically
quote them, and they get passed around as integral to the discussion as
the discussion itself.
I just jumped in because this is a pet peeve of mine. Some people seem to
think that patches are "binary files" just because they have whitespace
requirements and line-wrapping matters. But whitespace and line wrapping
is important even in regular discussion, and patches really _are_ about
the _human_ communication, just as much - and perhaps more so - as they
are about feeding to the "patch" program.
prev parent reply other threads:[~2006-12-03 18:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-03 0:45 [EGIT PATCH] Convert author and comment on demand Robin Rosenberg
2006-12-03 2:16 ` Shawn Pearce
2006-12-03 12:18 ` Robin Rosenberg
2006-12-03 12:34 ` Jakub Narebski
2006-12-03 18:08 ` Linus Torvalds [this message]
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=Pine.LNX.4.64.0612030955320.3476@woody.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).