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

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

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Wed, Jun 05, 2024 at 11:22:08AM GMT, Junio C Hamano wrote:
> > > Would it make sense to have git-format-patch (and friends) include an
> > > additional header hinting at the options used to generate the patch? E.g.:
> > >
> > >     X-git-diff-options: algo=myers; context=3;

Fwiw, I use format-patch command-line + options in the
--signature= switch when generating patches in WIP git repo viewer:

https://yhbt.net/lore/pub/scm/git/git.git/6549c41e/s/0001.patch

> > If you were to add a new e-mail header, wouldn't it make more sense
> > to add a patch-id header and agree on the set of options to be used
> > to generate that patch-id (which might be different from the setting
> > used to format the real patch for human and "git am" consumption)?
> 
> 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...

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.