Re: Reimagining notmuch-git/nmbug

Subject: Re: Reimagining notmuch-git/nmbug

Date: Wed, 5 Apr 2023 11:08:36 -0500

To: David Bremner

Cc: notmuch@notmuchmail.org

From: Felipe Contreras


On Tue, Apr 4, 2023 at 12:54 PM David Bremner <david@tethera.net> wrote:
>
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > On Mon, Apr 3, 2023 at 6:37 PM David Bremner <david@tethera.net> wrote:
>
> > Or we could say that after jumping a certain threshold of lastmod we
> > delete all the messages and start from scratch, perhaps every 1000
> > revisions.
> >
> > Or maybe the query could generate a virtual tag if a message was
> > deleted since the previous lastmod (e.g. "nm::deleted"). Then it would
> > be trivial for the remote helper to tell that to git.
>
> A complication here is that tags be attached to mail message documents
> in the database, so we would need to generate a so called "ghost
> message", and clean those up somehow.

I thought a little bit more about how I would use git-notmuch, and I
don't see the point in tracking messages that have no tags. In my view
the whole point of the tool is to backup the tags, and the whole point
of a backup is to eventually be able to restore it. But if there's
nothing to restore for a specific message, it might very well not
exist.

So instead of a `nm::deleted` tag, just no tags. I think from the
point of view of git-notmuch it shouldn't make a difference.

> > I lean towards the threshold, because that way the user doesn't need
> > to do anything, and there's no modifications needed in libnotmuch.
>
> This sounds right. Can we use the detection of missing messages in
> wr_export to reset the appropriate counters? It looks like yes, given
> the call to store_lastmod.

We would need to store them and use that information in the next
fetch. Although doable, it seems hacky, and in the past such things
have led to problems that are hard to solve due to inconsistent
states. For example what happens if in the next fetch we tell git that
some files have been removed, but we crash in the middle of it? The
next fetch we'll tell git that some files were removed, but git might
think they don't exist and fail. I think for that particular problem
git was fixed it shouldn't update the files unless the program exists
successfully, but I don't know.

I would rather go for a solution that is less hacky, and has less
chance of leaving the user in an unrecoverable state.

Cheers.

-- 
Felipe Contreras
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

Thread: