Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

diff --git a/da/2e3600399f7b4f3bdfd10626f681e16f557ffe b/da/2e3600399f7b4f3bdfd10626f681e16f557ffe
new file mode 100644 (file)
index 0000000..d5d025a
--- /dev/null
+++ b/da/2e3600399f7b4f3bdfd10626f681e16f557ffe
@@ -0,0 +1,96 @@
+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 678E8431FBD;\r
+       Fri,  4 Dec 2009 16:39:52 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\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 zOcqwOdmhFku; Fri,  4 Dec 2009 16:39:51 -0800 (PST)\r
+Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id ACCA7431FAE;\r
+       Fri,  4 Dec 2009 16:39:51 -0800 (PST)\r
+Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
+       id 642AA2542FB; Fri,  4 Dec 2009 16:39:51 -0800 (PST)\r
+From: Carl Worth <cworth@cworth.org>\r
+To: Michael Alan Dorman <mdorman@ironicdesign.com>, notmuch@notmuchmail.org\r
+In-Reply-To: <20091204140946.644243f0@vimes.local>\r
+References: <1259267025-28733-1-git-send-email-dottedmag@dottedmag.net>\r
+       <1259788526-14205-1-git-send-email-dottedmag@dottedmag.net>\r
+       <87zl5zfty5.fsf@yoom.home.cworth.org>\r
+       <87k4x29732.wl%bremner@pivot.cs.unb.ca>\r
+       <87bpiefwdq.fsf@yoom.home.cworth.org> <87aaxysjdj.fsf@vertex.dottedmag>\r
+       <87aaxyfuz4.fsf@yoom.home.cworth.org>\r
+       <20091204140946.644243f0@vimes.local>\r
+Date: Fri, 04 Dec 2009 16:39:50 -0800\r
+Message-ID: <87hbs6dzjd.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
+Subject: Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.12\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: Sat, 05 Dec 2009 00:39:52 -0000\r
+\r
+--=-=-=\r
+\r
+On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman <mdorman@ironicdesign.com> wrote:\r
+> Besides, in notmuch, what's the difference going to be?  It'll still be\r
+> threaded the same, etc., but you'd be able to tell that this one came\r
+> to you rather than through the list, no?\r
+\r
+There's one other point I should make here while talking about duplicate\r
+messages, (as determined by identical Message ID).\r
+\r
+Currently notmuch just indexes the first version of any given message it\r
+sees, and simply ignores anything else it sees in the future.\r
+\r
+We're planning to change it to at least save each of the filenames for\r
+messages with multiple files. That way if some duplicates are deleted,\r
+then notmuch will still be able to find one of the others.\r
+\r
+Also, we could make notmuch index duplicate messages and add any\r
+additional terms found to the document for the message. Currently, that\r
+wouldn't make a big difference since notmuch is only indexing the body\r
+and a few specific headers, (From, Subject, To, Cc, Bcc, Messsage-ID,\r
+In-Reply-To, References).\r
+\r
+So any differences there should be quite minor (a "[LIST]" prefix in\r
+subject? an extra footer in the boday?), under the assumption that no\r
+mail files will ever exist with the same message ID but disparate\r
+content.\r
+\r
+Now, we have a TODO item to allow for indexing additional headers,\r
+(either by default or by user configuration). Once we start doing that,\r
+it probably will make sense to at least index the duplicates.\r
+\r
+But when viewing an actual message, I'm still planning on having notmuch\r
+just return an arbitrary filename from the list of filenames associated\r
+with that message. Does anyone see any problem with that? Can you think\r
+of a case where you'd really care about seeing one or the other of\r
+a particular duplicated message?\r
+\r
+-Carl\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+\r
+iD8DBQFLGavX6JDdNq8qSWgRAlrKAJ4zzMlO7WSAT5N788hnxJtSGb2h3ACfRaXG\r
+nHhf4bQF7o6l7Q6HFQ9gkho=\r
+=5aC2\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r