Re: [PATCH v2 1/2] pretty: add X-Change-ID to mail formats

From: Drew DeVault <drew@ddevault.org>
Date: Jul 7, 2025, 07:09 UTC
Message-ID: <DB5MUUDPF6C0.3OR02N6JQB8H8@ddevault.org>
In-Reply-To: <xmqqfrf8ait6.fsf@gitster.g>

On Mon Jul 7, 2025 at 3:30 AM CEST, Junio C Hamano wrote:

Show 11 quoted lines

> I would suggest a lot more generic implementation to solve it once
> and for all.  How about doing it more like this:
>
>    "git format-patch --extra-headers" grabs all extra headers
>    (i.e. those that are not the bog-standard "tree", "parent",
>    "author", "committer") and emit these
>
>     X-git-extra-commit-header: encoding=iso8859-1
>     X-git-extra-commit-header: frotz=nitfol
>
>    next to "Subject:", etc.

+1. I particularly like how this approach throws out a bunch of arguing over the utility of the specific use-case -- clever :)

Do you think there's any reason not to throw all extra headers into X-git-extra-commit-header (or whatever) unconditionally? Does it need to be behind a flag or config option? If some tool added the extra commit headers, they presumably have a good reason for doing so and we ought to encode that information so we can reproduce the commit properly, same as we would with the rest of the commit headers.

I suppose there is a scenario where this breaks something because someone has a poorly thought-out string munging parser for git format-patch output that will barf upon encountering the unexpected, or some mail provider rejects emails rather than silently dropping headers it doesn't like, but both possibilities seem remote -- especially when considering that these hypothetical edge cases have to be combined with a use-case which deploys extra commit headers in the first place.