Konstantin Ryabitsev <konstan...@linuxfoundation.org> wrote: > Hello: > > I think public-inbox currently does some heuristic-based threading, > which may actually not be that useful. For example: > > https://lore.kernel.org/linux-renesas-soc/20200217101741.3758-1-geert+rene...@glider.be/ > > None of the [PATCH] messages have references or in-reply-to set, but for > some reason they are threaded together. I can generally see this being > useful for exact subject matches, but in this case all of the subjects > are different (despite being similar).
So the "Patchwork summary for: linux-renesas-soc" message: https://lore.kernel.org/linux-renesas-soc/158229483332.12219.5639020605006542672.git-patchwork-summ...@kernel.org/raw has the following header: References: <20200217101741.3758-1-geert+rene...@glider.be>, <20200218112414.5591-1-geert+rene...@glider.be>, <20200218112449.5723-1-geert+rene...@glider.be>, <20200219153929.11073-1-geert+rene...@glider.be>, <20200218132217.21454-1-geert+rene...@glider.be>, <20200217103251.5205-1-geert+rene...@glider.be> Which seems to have tied a bunch of unrelated threads together as one, similar to how a merge commit works in git but is unexpected and rare for mail threads. > Is there a way to enforce stricter threading rules? So I think the internal indexing database behavior is correct in tying a bunch of unrelated threads together based on that References: header. But the thread rendering could be improved. What mutt does seems alright, but doesn't convey the "merge" scenario (I think) your bot was going for... -- unsubscribe: one-click, see List-Unsubscribe header archive: https://public-inbox.org/meta/
