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

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Jun 5, 2024, 18:46 UTC
Message-ID: <20240605-zippy-wildcat-of-recreation-8c644e@lemur>
In-Reply-To: <xmqq5xuns10v.fsf@gitster.g>

On Wed, Jun 05, 2024 at 11:22:08AM GMT, Junio C Hamano wrote:

Show 8 quoted lines

> > 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@mail.gmail.com/