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=
Content-Type: text/plain; charset=UTF-8
From: Ben Gamari <bgamari@gmail.com>
To: martin f krafft <madduck@madduck.net>
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 <notmuch@notmuchmail.org>
Subject: Re: [notmuch] nested tag trees (was:  Mail in git)
Precedence: list

Excerpts from martin f krafft's message of Wed Feb 17 23:59:43 -0500 2010:
> also sprach Ben Gamari <bgamari@gmail.com> [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