On Mon Jul 7, 2025 at 3:30 AM CEST, Junio C Hamano wrote:
> 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.