RE: Reply all - issue

diff --git a/47/6687e01498bcfe47716fec84550b4a89a95bef b/47/6687e01498bcfe47716fec84550b4a89a95bef
new file mode 100644 (file)
index 0000000..3c1151f
--- /dev/null
+++ b/47/6687e01498bcfe47716fec84550b4a89a95bef
@@ -0,0 +1,102 @@
+Return-Path: <cworth@cworth.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 0B352431FB6\r
+       for <notmuch@notmuchmail.org>; Mon, 28 Jan 2013 18:44:54 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.01\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.01 tagged_above=-999 required=5\r
+       tests=[T_MIME_NO_TEXT=0.01] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id ZuQYcSllI8Iv for <notmuch@notmuchmail.org>;\r
+       Mon, 28 Jan 2013 18:44:53 -0800 (PST)\r
+Received: from arlo.cworth.org (arlo.cworth.org [50.126.95.6])\r
+       (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 5DC2A431FAE\r
+       for <notmuch@notmuchmail.org>; Mon, 28 Jan 2013 18:44:53 -0800 (PST)\r
+Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
+       by arlo.cworth.org (Postfix) with ESMTP id EF01C29A063;\r
+       Mon, 28 Jan 2013 18:44:51 -0800 (PST)\r
+Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
+       id C700A67855; Mon, 28 Jan 2013 18:47:33 -0800 (PST)\r
+From: Carl Worth <cworth@cworth.org>\r
+To: Robert Mast <beheerder@tekenbeetziekten.nl>,\r
+       'Jani Nikula' <jani@nikula.org>, notmuch@notmuchmail.org\r
+Subject: RE: Reply all - issue\r
+In-Reply-To: <002601cdfd83$83b283f0$8b178bd0$@nl>\r
+References: <000001cdfcd9$82500f00$86f02d00$@nl> <87wquxjq7k.fsf@nikula.org>\r
+       <002601cdfd83$83b283f0$8b178bd0$@nl>\r
+User-Agent: Notmuch/0.13.1 (http://notmuchmail.org) Emacs/23.4.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Tue, 29 Jan 2013 13:47:33 +1100\r
+Message-ID: <87boc8bt8a.fsf@yoom.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 29 Jan 2013 02:44:54 -0000\r
+\r
+--=-=-=\r
+\r
+Robert Mast <beheerder@tekenbeetziekten.nl> writes:\r
+> Your point on patch-breaking related to gmail and my proposal isn't\r
+> completely clear to me, but I've probably addressed it well with my new\r
+> approach.\r
+\r
+The issue here is that many developers tend to develop a patch series\r
+(perhaps with dozens of patches) as a single conceptual unit. When these\r
+are emailed out, they are often sent as one thread with a new subject\r
+for every patch. In particular, users of git and "git send-email" often\r
+send patches this way. For what it's worth, it's my preferred way to\r
+send and receive patches via email.\r
+\r
+It's extremely useful for messages like this to be presented as a\r
+single thread. This means that the dozens of messages don't clutter the\r
+inbox, and it also allows for an operation to act on all of the messages\r
+at once, (for example, notmuch provides "C-u |" which can apply all of\r
+the received patches to a code repository in a single operation).\r
+\r
+So, those of us accustomed to sending, receiving, reviewing, and\r
+applying patches emailed in this way would be basically unable to use an\r
+email program that split threads unconditionally on subject changes.\r
+\r
+So it may be tricky to find a single behavior that would make everyone\r
+happy. Perhaps a configuration option for splitting threads on subject\r
+changes.\r
+\r
+> I'll study the code for adding the option of unconditional (stripped)\r
+> subject breaking on top of the existing thread-breaking.\r
+\r
+Is there any existing thread-breaking? There wasn't the last time I\r
+looked at the code closely, (but admittedly, that was a while ago).\r
+\r
+-Carl\r
+\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.12 (GNU/Linux)\r
+\r
+iEYEARECAAYFAlEHOEUACgkQ6JDdNq8qSWgLlgCffo6q71opXZZ8zt3iCRQPQhIW\r
+9KMAmQGmrC8Y7y8WPbD29mBlpKVj3lkb\r
+=d9g7\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r