Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> 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.
