Re: thread merge/split proposal

[David Bremner <david@tethera.net>]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> That still doesn't cover the "notmuch unjoin" semantics i'd sketched out
> earlier, though.  that might need to be a different use case.
>
> The semantics would be something like:
>
>   break the selected threads into threads based solely on their
>   References headers (including any manual reference terms) using
>   connected component analysis, restoring the threading to what would be
>   produced on a clean import.

One thing I haven't understood is if the problem this is working around
is unavoidable due to the order messages arrive (or some other factor)
or if this is just a workaround for bugs in the threading algorithm. I'm
guessing the former, but can you explain why the problem is intractable
enough that the right answer is to reindex a thread (btw, that might be
a UI, to use the reindex command introduced in your indexed plaintex
patches).

d