From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id E2483431FBC for ; Wed, 17 Feb 2010 21:10:51 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599] autolearn=ham Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdNjwkh48E1F for ; Wed, 17 Feb 2010 21:10:51 -0800 (PST) Received: from mail-qy0-f187.google.com (mail-qy0-f187.google.com [209.85.221.187]) by olra.theworths.org (Postfix) with ESMTP id 22EF3431FAE for ; Wed, 17 Feb 2010 21:10:51 -0800 (PST) Received: by qyk17 with SMTP id 17so1154653qyk.2 for ; Wed, 17 Feb 2010 21:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:cc:subject:from :to:in-reply-to:references:date:message-id:user-agent :content-transfer-encoding; bh=9ZuTeHcuuyauuqqqFU+4qmkwGjyT5Ck1raMDCslbfuI=; b=to2od4fPEflITsQpmw5yCmtOsgBxDbQ+U2OKmOe1Eh1lUIycFMH71vRajX4EVIiXDK yPyqAFEENkaRCTtOn6CyUHFlbLClQ2fV9H/bfLoGMfzPauvdhmumWtBrHWe/pCoMBdpr lc3cO20Irb6Feod7QLpIDRV7m4SU/8Emg175A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:cc:subject:from:to:in-reply-to:references:date :message-id:user-agent:content-transfer-encoding; b=dkhSeEMg4F1Z2qA5UvFgk2O3c+Hyzv1/vAM5TflHv3BNQbq1bs7bvit9dRfuTupync CRI7JZa62MjMWKJ1yAYkYqfrhTErOfHw7VYqsUo7K4UoL4OnD7oU09s0IPq5b005rFXd uMgW+fv0tlOtxBz4iru+E7ttheHKmb/Q1rnMQ= Received: by 10.224.26.135 with SMTP id e7mr2216396qac.91.1266469850357; Wed, 17 Feb 2010 21:10:50 -0800 (PST) Received: from localhost (pool-96-236-125-203.spfdma.east.verizon.net [96.236.125.203]) by mx.google.com with ESMTPS id 6sm26979963qwd.16.2010.02.17.21.10.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Feb 2010 21:10:49 -0800 (PST) Content-Type: text/plain; charset=UTF-8 From: Ben Gamari To: martin f krafft In-reply-to: <20100218045943.GA6152@lapse.rw.madduck.net> References: <3wd3a0z7jjv.fsf@mhdcelk-nx01.amd.com> <1266435265-sup-5024@ben-laptop> <20100217235211.GC2628@lapse.rw.madduck.net> <1266453115-sup-7880@ben-laptop> <20100218015847.GB3480@lapse.rw.madduck.net> <1266459453-sup-7234@ben-laptop> <20100218024802.GA795@lapse.rw.madduck.net> <1266463007-sup-8777@ben-laptop> <20100218034613.GD1991@lapse.rw.madduck.net> <1266467977-sup-3504@ben-laptop> <20100218045943.GA6152@lapse.rw.madduck.net> Date: Thu, 18 Feb 2010 00:10:47 -0500 Message-Id: <1266469478-sup-2095@ben-laptop> User-Agent: Sup/git Content-Transfer-Encoding: 8bit Cc: notmuch Subject: Re: nested tag trees (was: Mail in git) X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 05:10:52 -0000 Excerpts from martin f krafft's message of Wed Feb 17 23:59:43 -0500 2010: > also sprach Ben Gamari [2010.02.18.1744 +1300]: > > I believe you would. The problem isn't the messages (well, that's > > a problem too), it's the fact that the tree (e.g. tab) objects > > which reference the messages are immutable (I believe). This > > presents us with the difficult circumstance of being unable to > > modify a tag after it has been created. Therefore, as far as I can > > tell, we need to rewrite the tag's tree object whenever we add or > > remove a message. This was the reason I suggested nesting tag > > trees, although this only partially solves the issue. > > You are absolutely right, and I think nesting tag trees is an > interesting idea to pursue. It *would* make it impossible to ever > check out the metatree into the filesystem, or rather result in > subdirectories that the user shouldn't need to worry about. > Yeah, this is a bit of a bummer. This is really a stretch, but I wonder if the git folks would accept patches/minor database semantics changes in the name of making git more flexible as a general purpose object database. I really doubt it, but you never know. > Instead of nested subtrees, think of 16 subtrees forming a level-1 > hash table, or 256 for level-2, which really *ought* to be enough. > > Anyway, rewriting a tree object is pretty much exactly the same as > removing a line (e.g. a message ID) from a file (e.g. a tag), as > that file would have to be fully rewritten. > This is very true, but exactly do you mean by this statement? > > Yeah, I'm not sure how well this would scale on truly massive mail > > stores. > > The more I think about this, the more I want to implement this > between evenless and Git, i.e. as a porcelain layer, since then > I could also use it for vcs-home[0]. In fact, maybe one day we can > store ~ and mail all in one Git repo, with different porcelains for > different use-cases, and notmuch indexing it all anyway. ;) It would be nice if git just didn't attach so many semantics to its object types and left more up to the porcelain. Git is a fantastic database, unfortunately it seems you need to work around a lot of VCS behavior in order to make use of it in a non-VCS application. Attaching less meaning to database objects would make things substantially easier. > Let's continue the technical discussion on the Git list, okay? > Yep. As soon as Majordomo sends me my confirmation. Cheers, - Ben