[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-02-15 Thread Stewart Smith
On Mon, Jan 25, 2010 at 01:46:59PM +1300, martin f krafft wrote: > Stewart, you've worked most on this so far. Would you like to share > your thoughts? Just posted a new thread with my latest experiments. Things look rather good from a storage size point of view. Still a few things to work out

Re: [notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-02-14 Thread Stewart Smith
On Mon, Jan 25, 2010 at 01:46:59PM +1300, martin f krafft wrote: Stewart, you've worked most on this so far. Would you like to share your thoughts? Just posted a new thread with my latest experiments. Things look rather good from a storage size point of view. Still a few things to work out

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-27 Thread Sebastian Spaeth
On Mon, 25 Jan 2010 14:49:00 +0100, "Sebastian Spaeth" wrote: > While notmuchsync fullfils my needs, it is a kludge. It needs to call > "notmuch" for each mail where a MailDir flag has changed (which can be > quite often on an initial run, where most mails are likely to be read), > this can take

Re: [notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-27 Thread Sebastian Spaeth
On Mon, 25 Jan 2010 14:49:00 +0100, Sebastian Spaeth sebast...@sspaeth.de wrote: While notmuchsync fullfils my needs, it is a kludge. It needs to call notmuch for each mail where a MailDir flag has changed (which can be quite often on an initial run, where most mails are likely to be read),

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-26 Thread martin f krafft
also sprach Sebastian Spaeth [2010.01.26.0249 +1300]: > While notmuchsync fullfils my needs, it is a kludge. It needs to > call "notmuch" for each mail where a MailDir flag has changed > (which can be quite often on an initial run, where most mails are > likely to be read), this can take a long,

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-25 Thread martin f krafft
also sprach Asheesh Laroia [2010.01.25.1819 +1300]: > You say "Ouch" but you should know Dovecot *already* does this. I > don't mind interoperating with that. > > See http://wiki.dovecot.org/MailboxFormat/Maildir, section "Issues > with the specification", subsection "Locking". I term this theQ >

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-25 Thread Sebastian Spaeth
On Mon, 25 Jan 2010 13:46:59 +1300, martin f krafft wrote: > I think we all kinda agreed that the Maildir flags should not be > used by notmuch and that things like Sebastian's notmuchsync should > be used if people wanted flags represented in Maildir filenames. While notmuchsync fullfils my

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-25 Thread martin f krafft
also sprach Asheesh Laroia [2010.01.21.1928 +1300]: > >I suppose that I never actually considered merges on the IMAP > >server side, but obviously the IMAP server has to work off a clone, > >and that means it needs to merge. > > It's not "merge" that's unsafe; that just builds a tree in the git

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-25 Thread Mike Kelly
On Mon, 25 Jan 2010 14:49:00 +0100, "Sebastian Spaeth" wrote: > > On Mon, 25 Jan 2010 13:46:59 +1300, martin f krafft > wrote: > > I think we all kinda agreed that the Maildir flags should not be > > used by notmuch and that things like Sebastian's notmuchsync should > > be used if people

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-25 Thread Asheesh Laroia
On Mon, 25 Jan 2010, martin f krafft wrote: > also sprach Asheesh Laroia [2010.01.21.1928 > +1300]: >>> I suppose that I never actually considered merges on the IMAP server >>> side, but obviously the IMAP server has to work off a clone, and that >>> means it needs to merge. >> >> It's not

Re: [notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-25 Thread Sebastian Spaeth
On Mon, 25 Jan 2010 13:46:59 +1300, martin f krafft madd...@madduck.net wrote: I think we all kinda agreed that the Maildir flags should not be used by notmuch and that things like Sebastian's notmuchsync should be used if people wanted flags represented in Maildir filenames. While

Re: [notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-25 Thread Mike Kelly
On Mon, 25 Jan 2010 14:49:00 +0100, Sebastian Spaeth sebast...@sspaeth.de wrote: On Mon, 25 Jan 2010 13:46:59 +1300, martin f krafft madd...@madduck.net wrote: I think we all kinda agreed that the Maildir flags should not be used by notmuch and that things like Sebastian's notmuchsync

Re: [notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-25 Thread martin f krafft
also sprach Sebastian Spaeth sebast...@sspaeth.de [2010.01.26.0249 +1300]: While notmuchsync fullfils my needs, it is a kludge. It needs to call notmuch for each mail where a MailDir flag has changed (which can be quite often on an initial run, where most mails are likely to be read), this can

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-24 Thread martin f krafft
also sprach Asheesh Laroia ashe...@asheesh.org [2010.01.21.1928 +1300]: I suppose that I never actually considered merges on the IMAP server side, but obviously the IMAP server has to work off a clone, and that means it needs to merge. It's not merge that's unsafe; that just builds a tree in

Re: [notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

2010-01-24 Thread martin f krafft
also sprach Asheesh Laroia ashe...@asheesh.org [2010.01.25.1819 +1300]: You say Ouch but you should know Dovecot *already* does this. I don't mind interoperating with that. See http://wiki.dovecot.org/MailboxFormat/Maildir, section Issues with the specification, subsection Locking. I term