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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 7, 2025, 12:40 UTC
Message-ID: <xmqqecus6uno.fsf@gitster.g>
In-Reply-To: <CAESOdVD-gWts6H-pSFBQfVn02nPBT1b0Xpfzp8Hea-QXsEA_TQ@mail.gmail.com>

Martin von Zweigbergk <martinvonz@google.com> writes:

Show 8 quoted lines

>> 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", ...

Show 5 quoted lines

>> 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.