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;
>
> I doubt it. And newer version of Git _will_ try to improve how
> patch text appears to be more useful to human users, so you have
> more moving parts than you'd want to even think about enumerating.
OK, I was afraid that was the case.
> 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.
I'm always happy to see a Link: trailer pointing at the patch submission,
e.g.:
| Link: https://msgid.link/[msgid]
However, not all maintainers welcome them in commits (e.g. Linus was vocal
about it in the past [1]). It could be the case of "use them anyway," but
we'll still have a large enough subset of commits without this info and
increasingly without a reliable mechanism to map commits to original
submissions and code review systems.
I'm not sure if there's a reliable way to solve this.
-K
[1]: https://lore.kernel.org/lkml/CAHk-=wgAk3NEJ2PHtb0jXzCUOGytiHLq=rzjkFKfpiuH-SROgA@xxxxxxxxxxxxxx/
