Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Nov 28, 2023 at 05:35:09PM +0000, Eric Wong wrote: > > > I understand the reasoning, but I'm not sure we should be trying too hard to > > > make public-inbox a patch tracking platform. What makes lei great is ability > > > to automatically find and retrieve entire threads -- I feel like we should > > > leave series tracking to other platforms that already exist (patchwork, > > > patchew, etc). > > > > I was thinking more along the lines of readers just trying to > > find trying to find non-patch discussions. > > Ah. I think here is enough to just say "s:* AND NOT s:PATCH" without > introducing additional xapian indexing parameters. Though, perhaps the web > interface can also gain a "collapse threads" view? topics_new.html / topics_active.html endpoints? Also, '&t' is a weird accident that happens to work: https://yhbt.net/lore/git/?q=s:*+AND+NOT+s:PATCH&t I suppose that's OK for the majority of cases. Though being able to find unanswered threads could be helpful. > > > This made me realize that there's actually a multitude of ways the same patch > > > can be represented (diff-algorithm, number of context lines, etc) that would > > > cause git-patch-id to return a different value for the exact same commit. > > > > Yeah, post-image blob abbreviations are probably the way to go. > > > > Fwiw, solver only uses post-image blob abbreviations and the > > filename as a hint. I rolled it out a few hours ago on yhbt.net/lore > > and it seems to be solving kernel blobs just fine, but the > > debug log is choosing random git URLs. > > Ah, neat! That said, what happens if a series was applied with "git am -3" and > the post-image blob abbreviations are necessarily different? (I may be > misunderstanding the approach, please correct me if I do.) The resulting blob will be retrievable directly via git once it's pushed to a mirrored repo. solver tries to look for a blob in git, first, before trying to search+apply patches[1]. Right now I'm only clamping to 3 coderepos for performance reasons, but that limitation is going away. But I need a nap, first :x [1] solver could reverse the order to look for the mails first if we wanted to see the fullest email history of a blob, but it's much slower because it has to do a lot more work (hitting Xapian and runing git apply+ls-files for every single patch).
