Re: extra search flags and params? (ispatch, replycount, ...)

[Eric Wong <e@80x24.org>]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Tue, Nov 28, 2023 at 12:10:28AM +0000, Eric Wong wrote:
> > Would they be useful?
> > 
> > It's not currently possible to quickly search for whether or not
> > a term (e.g. patchid:) is present in a Xapian document.  Having
> > the ability to do so would make it easier to find non-patch messages,
> > or easily filter down to cover letters, bot replies, etc...
> 
> 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.  I'm not really
interested in the tracking part, more just being able to quickly
find discussion related to a commit.

> > I don't think any of these would be required to get "lei rediff"
> > working on entire patchsets, though (it only does individual
> > messages, currently).
> 
> Incidentally, I've recently discovered that relying on git-patch-id to match
> commits to message archives has some important flaws. Linus was actually the
> one who caused this when he recommended that maintainers switch to using the
> "histogram" diff algorithm instead of the default ("myers").

Yeah, -cindex was actually built to support joins on pre or post-image
blob OIDs, too, just need to clamp to a 7 char hex abbreviation.
Even Subjects <=> commit titles could be made to work with the
way our indices are setup.

> 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.

(Solver is the thing that powers `lei rediff' and the linkified
hunk headers on public-inbox.org/git since 2019, and now yhbt.net/lore)