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

From: Junio C Hamano <[email-masked]>
Date: Mon, 07 Jul 2025 05:40:43 -0700

Martin von Zweigbergk <[email-masked]> writes:

>> Does this also apply to commit signatures? I just created a signed
>> commit and checked what `git format-patch` produces. I was a bit
>> surprised to see that it doesn't seem to show up anywhere. Is it not
>> supported or did I miss some flag or config?
>
> Oh, perhaps they're deliberately not included because the commit
> timestamp is not included in the patch so the signatures would be
> invalid even if the patch was applied to the right parent?

An excellent observation.

Yes, it was a deliberate design decision to omit cryptographic
signature(s) on the commit object itself, based on the assumption
that the primary motivation behind e-mailed patch workflow is to
convey the essense of the change in a readable form, while allowing
minor modifications to both proposed log message and the diff
while/before applying it, and on top of a state that is slightly
different from the state the patch was taken from.  It was out of
scope to reproduce the history bit-for-bit identically.  Besides the
author timestamp, the committer timestamp and identity (the
recipient of an e-mailed patch is likely to be different from the
sender), "git am -s --whitespace=fix" would be a common thing a
recipient would want to clean up the patch sent over the e-mail
anyway.

But with many past design decisions, the underlying assumptions are
worth reevaluating from time to time.  They may have become
outdated, or new use cases may have emerged that the tools are good
fit to support them with enhancements.

Instead of only limiting to convey the essense in a readable form,
we could also aim to support the exact bit-for-bit reproducibility
under certain conditions, e.g., the recipient has exact objects
named by the "tree" and "parent" headers in the original commit
object.  Think of it as an e-mailable bundle file whose contents can
be inspected before unbundling.

And for such a "inspectable and e-mailable bundle that can be used
to fully reproduce the state bit-for-bit", ...

>> Is it another option to put it somewhere in the body? Could we fit
>> additional headers (e.g. signatures and third-party ones) somewhere
>> between the `---` line and the additional diff? Or how about after the
>> final `--` line? I haven't checked the specification. I just saw these
>> lines in the `git format-patch` output.

... I think a far simpler and more robust approach is to dump the
whole "git cat-file commit" output somewhere in the e-mail, not
limiting ourselves to "extra" headers, in some "less susceptible to
corruption" form (e.g. base85).  The standard headers like "tree"
and "parent" are good thing to have if a new requirement is to allow
exact reproducibility when the objects the patch was based on exist,
and the raw commit message with trailing whitespaces would be needed
in a protected form as well, since e-mailed patches can lose them
during transit.

And below the three-dash line as you suggested is one good place to
keep such an extra piece of information.

Or the "cat-file commit" dump can be on an extra e-mail header.

Some e-mail environments will deliberately hide anything after the
final "-- " (signature) line, and saving a message may even lose it,
so it is not a good place to store anything that is worth feeding
"git am" with.

Thanks.