Re: RFC: indicating diff strategy in format-patch message headers

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Jun 7, 2024, 19:53 UTC
Message-ID: <20240607-ultra-unicorn-of-democracy-d25a69@lemur>
In-Reply-To: <20240605222658.M32384@dcvr>

On Wed, Jun 05, 2024 at 10:26:58PM GMT, Eric Wong wrote:

Show 5 quoted lines

> > That would be redundant with the message-id. Unfortunately, this doesn't solve
> > the problem of how to reliably map a commit to the patch from which it
> > originated, other than using the Message-ID: or Link: trailers.
> 
> dfpre:, dfblob:, dfpost: search queries on lore seem to work...

I've thought about that, but this is also not very reliable, at least not when patch series are applied as fast-forwards, not merges. Unfortunately, some projects enforce a flat history (glibc, gcc), with merges being specifically not allowed -- which means dfblob matching is not going to match a lot of commits.

Show 13 quoted lines

> On my lore + gko mirror, the #related search off a commit mostly
> works for a single extindex, but mapping hundreds of forks to
> hundreds of inboxes with a presentable UI for w3m||lynx users is
> a different matter I haven't been able to solve:
> 
> https://yhbt.net/lore/pub/scm/git/git.git/6549c41e/s/#related
> 
> > I'm not sure if there's a reliable way to solve this.
> 
> I started working on a scoring mechanism a while back but got
> distracted with personal matters.  UI is hard, and dealing with
> my gko mirror has been a source of pain due to various
> memory+performance problems.

I can totally relate to the pain of memory+performance problems. :) Especially when a ton of "AI" bots decide to aggressively crawl your sites. :/

-K