On Mon, Apr 3, 2023 at 6:37 PM David Bremner <da...@tethera.net> wrote: > > Felipe Contreras <felipe.contre...@gmail.com> writes: > > > > > That should work to update existing tags, but how are we going to > > detect if a message has disappeared? Or is that not a thing? > > Indeed the same thought had occurred to me not long ago. I remembered > (belately) that I'd been through some similar thought process with nmbug. > Messages can and do disappear. So for I guess that optimization not OK, > at least not without some complications. > > > Does "lastmod:0.." get all the revisions? If so, it might make sense > > to set $lastmod to 0 initially. > > > > Then we could unconditionally do: > > > > $db.query('lastmod:%d..' % $lastmod, sort: Notmuch::SORT_UNSORTED) > > That would work, but as you point out, we'd need to deal with deletions > somehow. It occurs to me that wr_export also needs to be able to handle > disappearing message-ids. I suppose like notmuch-restore it can just > complain and skip any missing ones. It's tempting to try to do some kind > of lazy cleanup at that point, but I don't really see how that fits with > the remote-helper protocol.
We could have an external tool, something like `git-notmuch-fsck` or something that the user has to regularly execute, as `git fsck` was in the past. 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. I lean towards the threshold, because that way the user doesn't need to do anything, and there's no modifications needed in libnotmuch. Cheers. -- Felipe Contreras _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org