65/86441dc70b027a50edca168228a46c8f1e6270

   1 Return-Path: <bgamari@gmail.com>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id E2483431FBC\r
   6         for <notmuch@notmuchmail.org>; Wed, 17 Feb 2010 21:10:51 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.186\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.413,\r
  12         BAYES_00=-2.599] autolearn=ham\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id OdNjwkh48E1F for <notmuch@notmuchmail.org>;\r
  16         Wed, 17 Feb 2010 21:10:51 -0800 (PST)\r
  17 Received: from mail-qy0-f187.google.com (mail-qy0-f187.google.com\r
  18         [209.85.221.187])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 22EF3431FAE\r
  20         for <notmuch@notmuchmail.org>; Wed, 17 Feb 2010 21:10:51 -0800 (PST)\r
  21 Received: by qyk17 with SMTP id 17so1154653qyk.2\r
  22         for <notmuch@notmuchmail.org>; Wed, 17 Feb 2010 21:10:50 -0800 (PST)\r
  23 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  24         h=domainkey-signature:received:received:content-type:cc:subject:from\r
  25         :to:in-reply-to:references:date:message-id:user-agent\r
  26         :content-transfer-encoding;\r
  27         bh=9ZuTeHcuuyauuqqqFU+4qmkwGjyT5Ck1raMDCslbfuI=;\r
  28         b=to2od4fPEflITsQpmw5yCmtOsgBxDbQ+U2OKmOe1Eh1lUIycFMH71vRajX4EVIiXDK\r
  29         yPyqAFEENkaRCTtOn6CyUHFlbLClQ2fV9H/bfLoGMfzPauvdhmumWtBrHWe/pCoMBdpr\r
  30         lc3cO20Irb6Feod7QLpIDRV7m4SU/8Emg175A=\r
  31 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  32         h=content-type:cc:subject:from:to:in-reply-to:references:date\r
  33         :message-id:user-agent:content-transfer-encoding;\r
  34         b=dkhSeEMg4F1Z2qA5UvFgk2O3c+Hyzv1/vAM5TflHv3BNQbq1bs7bvit9dRfuTupync\r
  35         CRI7JZa62MjMWKJ1yAYkYqfrhTErOfHw7VYqsUo7K4UoL4OnD7oU09s0IPq5b005rFXd\r
  36         uMgW+fv0tlOtxBz4iru+E7ttheHKmb/Q1rnMQ=\r
  37 Received: by 10.224.26.135 with SMTP id e7mr2216396qac.91.1266469850357;\r
  38         Wed, 17 Feb 2010 21:10:50 -0800 (PST)\r
  39 Received: from localhost (pool-96-236-125-203.spfdma.east.verizon.net\r
  40         [96.236.125.203])\r
  41         by mx.google.com with ESMTPS id 6sm26979963qwd.16.2010.02.17.21.10.48\r
  42         (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
  43         Wed, 17 Feb 2010 21:10:49 -0800 (PST)\r
  44 Content-Type: text/plain; charset=UTF-8\r
  45 From: Ben Gamari <bgamari@gmail.com>\r
  46 To: martin f krafft <madduck@madduck.net>\r
  47 In-reply-to: <20100218045943.GA6152@lapse.rw.madduck.net>\r
  48 References: <3wd3a0z7jjv.fsf@mhdcelk-nx01.amd.com>\r
  49         <1266435265-sup-5024@ben-laptop>\r
  50         <20100217235211.GC2628@lapse.rw.madduck.net>\r
  51         <1266453115-sup-7880@ben-laptop>\r
  52         <20100218015847.GB3480@lapse.rw.madduck.net>\r
  53         <1266459453-sup-7234@ben-laptop>\r
  54         <20100218024802.GA795@lapse.rw.madduck.net>\r
  55         <1266463007-sup-8777@ben-laptop>\r
  56         <20100218034613.GD1991@lapse.rw.madduck.net>\r
  57         <1266467977-sup-3504@ben-laptop>\r
  58         <20100218045943.GA6152@lapse.rw.madduck.net>\r
  59 Date: Thu, 18 Feb 2010 00:10:47 -0500\r
  60 Message-Id: <1266469478-sup-2095@ben-laptop>\r
  61 User-Agent: Sup/git\r
  62 Content-Transfer-Encoding: 8bit\r
  63 Cc: notmuch <notmuch@notmuchmail.org>\r
  64 Subject: Re: [notmuch] nested tag trees (was:  Mail in git)\r
  65 X-BeenThere: notmuch@notmuchmail.org\r
  66 X-Mailman-Version: 2.1.13\r
  67 Precedence: list\r
  68 List-Id: "Use and development of the notmuch mail system."\r
  69         <notmuch.notmuchmail.org>\r
  70 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  71         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  72 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  73 List-Post: <mailto:notmuch@notmuchmail.org>\r
  74 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  75 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  76         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  77 X-List-Received-Date: Thu, 18 Feb 2010 05:10:52 -0000\r
  78 \r
  79 Excerpts from martin f krafft's message of Wed Feb 17 23:59:43 -0500 2010:\r
  80 > also sprach Ben Gamari <bgamari@gmail.com> [2010.02.18.1744 +1300]:\r
  81 > > I believe you would. The problem isn't the messages (well, that's\r
  82 > > a problem too), it's the fact that the tree (e.g. tab) objects\r
  83 > > which reference the messages are immutable (I believe). This\r
  84 > > presents us with the difficult circumstance of being unable to\r
  85 > > modify a tag after it has been created. Therefore, as far as I can\r
  86 > > tell, we need to rewrite the tag's tree object whenever we add or\r
  87 > > remove a message. This was the reason I suggested nesting tag\r
  88 > > trees, although this only partially solves the issue.\r
  89 > \r
  90 > You are absolutely right, and I think nesting tag trees is an\r
  91 > interesting idea to pursue. It *would* make it impossible to ever\r
  92 > check out the metatree into the filesystem, or rather result in\r
  93 > subdirectories that the user shouldn't need to worry about.\r
  94 > \r
  95 Yeah, this is a bit of a bummer. This is really a stretch, but I wonder\r
  96 if the git folks would accept patches/minor database semantics changes\r
  97 in the name of making git more flexible as a general purpose object\r
  98 database. I really doubt it, but you never know.\r
  99 \r
 100 > Instead of nested subtrees, think of 16 subtrees forming a level-1\r
 101 > hash table, or 256 for level-2, which really *ought* to be enough.\r
 102 > \r
 103 > Anyway, rewriting a tree object is pretty much exactly the same as\r
 104 > removing a line (e.g. a message ID) from a file (e.g. a tag), as\r
 105 > that file would have to be fully rewritten.\r
 106 > \r
 107 This is very true, but exactly do you mean by this statement?\r
 108 \r
 109 > > Yeah, I'm not sure how well this would scale on truly massive mail\r
 110 > > stores.\r
 111 > \r
 112 > The more I think about this, the more I want to implement this\r
 113 > between evenless and Git, i.e. as a porcelain layer, since then\r
 114 > I could also use it for vcs-home[0]. In fact, maybe one day we can\r
 115 > store ~ and mail all in one Git repo, with different porcelains for\r
 116 > different use-cases, and notmuch indexing it all anyway. ;)\r
 117 \r
 118 It would be nice if git just didn't attach so many semantics to its\r
 119 object types and left more up to the porcelain. Git is a fantastic\r
 120 database, unfortunately it seems you need to work around a lot of VCS\r
 121 behavior in order to make use of it in a non-VCS application. Attaching\r
 122 less meaning to database objects would make things substantially easier.\r
 123 \r
 124 > Let's continue the technical discussion on the Git list, okay?\r
 125 > \r
 126 \r
 127 Yep. As soon as Majordomo sends me my confirmation.\r
 128 \r
 129 Cheers,\r
 130 \r
 131 - Ben\r