Re: [notmuch] Mail in git
authorStewart Smith <stewart@flamingspork.com>
Wed, 17 Feb 2010 23:56:53 +0000 (10:56 +1100)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:36:13 +0000 (09:36 -0800)
b2/f53c3d81b959f05d87d5bcfcc8ba1710829733 [new file with mode: 0644]

diff --git a/b2/f53c3d81b959f05d87d5bcfcc8ba1710829733 b/b2/f53c3d81b959f05d87d5bcfcc8ba1710829733
new file mode 100644 (file)
index 0000000..d98032a
--- /dev/null
@@ -0,0 +1,91 @@
+Return-Path: <stewart@flamingspork.com>\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 C52CB431FBC\r
+       for <notmuch@notmuchmail.org>; Wed, 17 Feb 2010 15:56:56 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.715\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5\r
+       tests=[AWL=-0.716, BAYES_50=0.001] autolearn=ham\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 53Ap7925gMxp for <notmuch@notmuchmail.org>;\r
+       Wed, 17 Feb 2010 15:56:56 -0800 (PST)\r
+Received: from kaylee.flamingspork.com (kaylee.flamingspork.com\r
+       [74.207.245.61])\r
+       by olra.theworths.org (Postfix) with ESMTP id 25449431FAE\r
+       for <notmuch@notmuchmail.org>; Wed, 17 Feb 2010 15:56:56 -0800 (PST)\r
+Received: from willster (localhost [127.0.0.1])\r
+       by kaylee.flamingspork.com (Postfix) with ESMTPS id 1607E632D;\r
+       Wed, 17 Feb 2010 23:53:50 +0000 (UTC)\r
+Received: by willster (Postfix, from userid 1000)\r
+       id 31B67106A956; Thu, 18 Feb 2010 10:56:53 +1100 (EST)\r
+From: Stewart Smith <stewart@flamingspork.com>\r
+To: martin f krafft <madduck@madduck.net>, notmuch@notmuchmail.org\r
+In-Reply-To: <20100217012101.GD8249@lapse.rw.madduck.net>\r
+References: <20100215002914.GA22402@flamingspork.com>\r
+       <20100217012101.GD8249@lapse.rw.madduck.net>\r
+Date: Thu, 18 Feb 2010 10:56:53 +1100\r
+Message-ID: <87ljerju0q.fsf@willster.local.flamingspork.com>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Transfer-Encoding: quoted-printable\r
+Subject: Re: [notmuch] Mail in git\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: Wed, 17 Feb 2010 23:56:56 -0000\r
+\r
+On Wed, 17 Feb 2010 14:21:01 +1300, martin f krafft <madduck@madduck.net> w=\r
+rote:\r
+> What I am wondering is if (explicit) tags couldn't be represented as\r
+> tree-objects with this.\r
+>=20\r
+>   evenless-link   =E2=80=94 link a message object with a tree object\r
+>   evenless=E2=80=93unlink =E2=80=93 unlink a message object from tree obj=\r
+ect\r
+>     [replaces evenless-unlink]\r
+\r
+I think it could get expensive for tags with lots of messages.\r
+\r
+With my fast-import script, doing the commit (that\r
+referenced... umm.. 800,000+ objects took a *very* long time).\r
+\r
+As far as I understand it, the tree object is stored in full and space\r
+is only reclaimed during repack (due to delta compression).\r
+\r
+So if you, say, had the entire history of a high volume list such as\r
+linux-kernel, adding messages could get rather expensive if you\r
+auto-tagged (or autotagged messages with patches or whatever).\r
+\r
+> messages would then be deleted whenever using git-gc.\r
+>=20\r
+> No idea how this would sync if we don't keep ancestry. Otoh, it\r
+> would probably not be very expensive to do just that.\r
+\r
+If we keep ancestry though, we are reusing existing working code for\r
+backup (git-pull :)\r
+\r
+Keep in mind that with my tests, the Maildir in git is about a quarter\r
+to a fifth of the size of it in Maildir... so a bit of extra usage per\r
+message isn't as dramatic as it may sound.\r
+\r
+> Is it possible to find out all trees that reference a given object\r
+> with Git in constant or sub-linear time?\r
+\r
+I don't think so.... but I'm not sure.\r
+\r
+--=20\r
+Stewart Smith\r