[notmuch] Mail in git

2011-05-21 Thread Stewart Smith
On Sat, 21 May 2011 09:05:54 +0200, martin f krafft wrote: > Has anyone worked on this since? No, haven't had the cycles... and SSD helped a bit to delay urgency. -- Stewart Smith

[notmuch] Mail in git

2011-05-21 Thread martin f krafft
also sprach Stewart Smith [2010.02.17.1107 +0100]: > On Wed, 17 Feb 2010 11:21:51 +1100, Stewart Smith flamingspork.com> wrote: > > Using fast-import is interesting. Does it update the working tree? The > > big thing I wanted to avoid was creating a working tree (another million > > inodes being

Re: [notmuch] Mail in git

2011-05-21 Thread martin f krafft
also sprach Stewart Smith stew...@flamingspork.com [2010.02.17.1107 +0100]: On Wed, 17 Feb 2010 11:21:51 +1100, Stewart Smith stew...@flamingspork.com wrote: Using fast-import is interesting. Does it update the working tree? The big thing I wanted to avoid was creating a working tree

Re: [notmuch] Mail in git

2011-05-21 Thread Stewart Smith
On Sat, 21 May 2011 09:05:54 +0200, martin f krafft madd...@madduck.net wrote: Has anyone worked on this since? No, haven't had the cycles... and SSD helped a bit to delay urgency. -- Stewart Smith ___ notmuch mailing list notmuch@notmuchmail.org

[notmuch] Mail in git

2010-02-18 Thread martin f krafft
also sprach Ben Gamari [2010.02.18.1401 +1300]: > > If we keep ancestry though, we are reusing existing working code for > > backup (git-pull :) > > This is one of the reasons I feel it's important we keep it. And as is > stated below, the storage overhead is minimal. Absolutely; Stewart

[notmuch] Mail in git

2010-02-18 Thread martin f krafft
also sprach Ben Gamari [2010.02.18.1339 +1300]: > Yes, it would be linear in number of tags. I suppose if messages > weren't stored in the top-level tree nodes, then it would still be > linear, although with a slope equal to the reciprocal of the fan-out. > This has the potential to be very

[notmuch] Mail in git

2010-02-18 Thread martin f krafft
also sprach Ben Gamari [2010.02.18.0834 +1300]: > Excerpts from Mark Anderson's message of Wed Feb 17 14:23:48 -0500 > 2010: > > But if we have notmuch as a cache of the tags, then don't we > > already know the tree objects that need updating? Yes, we would > > probably need some consistency

[notmuch] Mail in git

2010-02-18 Thread Stewart Smith
On Wed, 17 Feb 2010 14:21:01 +1300, martin f krafft wrote: > What I am wondering is if (explicit) tags couldn't be represented as > tree-objects with this. > > evenless-link ? link a message object with a tree object > evenless?unlink ? unlink a message object from tree object >

[notmuch] Mail in git

2010-02-17 Thread Ben Gamari
Excerpts from martin f krafft's message of Wed Feb 17 20:58:47 -0500 2010: > also sprach Ben Gamari [2010.02.18.1339 +1300]: > > Yes, it would be linear in number of tags. I suppose if messages > > weren't stored in the top-level tree nodes, then it would still be > > linear, although with a

[notmuch] Mail in git

2010-02-17 Thread Stewart Smith
On Wed, 17 Feb 2010 11:21:51 +1100, Stewart Smith wrote: > Using fast-import is interesting. Does it update the working tree? The > big thing I wanted to avoid was creating a working tree (another million > inodes being created is not ever what I need) > > Also interesting is the mention of

[notmuch] Mail in git

2010-02-17 Thread Ben Gamari
Excerpts from Stewart Smith's message of Wed Feb 17 18:56:53 -0500 2010: > On Wed, 17 Feb 2010 14:21:01 +1300, martin f krafft > wrote: > > What I am wondering is if (explicit) tags couldn't be represented as > > tree-objects with this. > > I think it could get expensive for tags with lots of

[notmuch] Mail in git

2010-02-17 Thread Ben Gamari
Excerpts from martin f krafft's message of Wed Feb 17 18:52:11 -0500 2010: > also sprach Ben Gamari [2010.02.18.0834 +1300]: > > Excerpts from Mark Anderson's message of Wed Feb 17 14:23:48 -0500 > > 2010: > > > But if we have notmuch as a cache of the tags, then don't we > > > already know the

[notmuch] Mail in git

2010-02-17 Thread Ben Gamari
Excerpts from Mark Anderson's message of Wed Feb 17 14:23:48 -0500 2010: > But if we have notmuch as a cache of the tags, then don't we already > know the tree objects that need updating? Yes, we would probably need > some consistency checks for when things don't work as planned, but in > the

[notmuch] Mail in git

2010-02-17 Thread martin f krafft
also sprach Stewart Smith [2010.02.15.1329 +1300]: > What about adding more mail to the archive? > > So the way I think is that you use a Maildir for day to day mail > (e.g. delivery) and every so often you run some magic command that > takes old mail out of the Maildir and stores it in the git

[notmuch] Mail in git

2010-02-17 Thread Mark Anderson
On Wed, 17 Feb 2010 10:03:36 -0500, Ben Gamari wrote: > > notmuch would then only search and provide the hash ID(s); tags > > would be a function of storage. > > > > Is it possible to find out all trees that reference a given object > > with Git in constant or sub-linear time? > > > I don't

[notmuch] Mail in git

2010-02-17 Thread Stewart Smith
On Tue, 16 Feb 2010 14:06:29 -0500, Ben Gamari wrote: > Excerpts from Stewart Smith's message of Sun Feb 14 19:29:14 -0500 2010: > > So... I sketched this out in my head at LCA... and it's taken a bit of > > time to actually properly try it. > > > In case anyone wanted to play around with this,

[notmuch] Mail in git

2010-02-17 Thread Ben Gamari
Excerpts from martin f krafft's message of Tue Feb 16 20:21:01 -0500 2010: > What I am wondering is if (explicit) tags couldn't be represented as > tree-objects with this. > > evenless-link ? link a message object with a tree object > evenless?unlink ? unlink a message object from tree

Re: [notmuch] Mail in git

2010-02-17 Thread Stewart Smith
On Wed, 17 Feb 2010 11:21:51 +1100, Stewart Smith stew...@flamingspork.com wrote: Using fast-import is interesting. Does it update the working tree? The big thing I wanted to avoid was creating a working tree (another million inodes being created is not ever what I need) Also interesting is

Re: [notmuch] Mail in git

2010-02-17 Thread Mark Anderson
On Wed, 17 Feb 2010 10:03:36 -0500, Ben Gamari bgam...@gmail.com wrote: notmuch would then only search and provide the hash ID(s); tags would be a function of storage. Is it possible to find out all trees that reference a given object with Git in constant or sub-linear time? I don't

Re: [notmuch] Mail in git

2010-02-17 Thread martin f krafft
also sprach Ben Gamari bgam...@gmail.com [2010.02.18.0834 +1300]: Excerpts from Mark Anderson's message of Wed Feb 17 14:23:48 -0500 2010: But if we have notmuch as a cache of the tags, then don't we already know the tree objects that need updating? Yes, we would probably need some

Re: [notmuch] Mail in git

2010-02-17 Thread Stewart Smith
On Wed, 17 Feb 2010 14:21:01 +1300, martin f krafft madd...@madduck.net wrote: What I am wondering is if (explicit) tags couldn't be represented as tree-objects with this. evenless-link — link a message object with a tree object evenless–unlink – unlink a message object from tree

Re: [notmuch] Mail in git

2010-02-17 Thread Ben Gamari
Excerpts from martin f krafft's message of Wed Feb 17 18:52:11 -0500 2010: also sprach Ben Gamari bgam...@gmail.com [2010.02.18.0834 +1300]: Excerpts from Mark Anderson's message of Wed Feb 17 14:23:48 -0500 2010: But if we have notmuch as a cache of the tags, then don't we already know

Re: [notmuch] Mail in git

2010-02-17 Thread martin f krafft
also sprach Ben Gamari bgam...@gmail.com [2010.02.18.1401 +1300]: If we keep ancestry though, we are reusing existing working code for backup (git-pull :) This is one of the reasons I feel it's important we keep it. And as is stated below, the storage overhead is minimal. Absolutely;

Re: [notmuch] Mail in git

2010-02-17 Thread Ben Gamari
Excerpts from martin f krafft's message of Wed Feb 17 20:58:47 -0500 2010: also sprach Ben Gamari bgam...@gmail.com [2010.02.18.1339 +1300]: Yes, it would be linear in number of tags. I suppose if messages weren't stored in the top-level tree nodes, then it would still be linear, although

[notmuch] Mail in git

2010-02-16 Thread Ben Gamari
Excerpts from Stewart Smith's message of Sun Feb 14 19:29:14 -0500 2010: > So... I sketched this out in my head at LCA... and it's taken a bit of > time to actually properly try it. > In case anyone wanted to play around with this, I've written up my own little implementation[1] of a git mail

[notmuch] Mail in git

2010-02-16 Thread Michal Sojka
Hi Stewart, On Mon, 15 Feb 2010 11:29:14 +1100, Stewart Smith wrote: > Which goes from a 15GB Maildir to a 3.7GB git repo. That's quite interesting ratio. I've tried a plain git add and git gc on my mail store and the result was a repo of approximately 50% of mail store size. Do you think that

Re: [notmuch] Mail in git

2010-02-16 Thread Michal Sojka
Hi Stewart, On Mon, 15 Feb 2010 11:29:14 +1100, Stewart Smith stew...@flamingspork.com wrote: Which goes from a 15GB Maildir to a 3.7GB git repo. That's quite interesting ratio. I've tried a plain git add and git gc on my mail store and the result was a repo of approximately 50% of mail store

Re: [notmuch] Mail in git

2010-02-16 Thread martin f krafft
also sprach Stewart Smith stew...@flamingspork.com [2010.02.15.1329 +1300]: What about adding more mail to the archive? So the way I think is that you use a Maildir for day to day mail (e.g. delivery) and every so often you run some magic command that takes old mail out of the Maildir and

[notmuch] Mail in git

2010-02-15 Thread Stewart Smith
So... I sketched this out in my head at LCA... and it's taken a bit of time to actually properly try it. The problem is: A simple 'find ~/Maildir` takes 10 minutes, and if you write the output to a file, it's 88MB+ there's "only" about 900,000 entries there. But this means 900,000 files, which

[notmuch] Mail in git

2010-02-14 Thread Stewart Smith
So... I sketched this out in my head at LCA... and it's taken a bit of time to actually properly try it. The problem is: A simple 'find ~/Maildir` takes 10 minutes, and if you write the output to a file, it's 88MB+ there's only about 900,000 entries there. But this means 900,000 files, which is