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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 7, 2025, 01:30 UTC
Message-ID: <xmqqfrf8ait6.fsf@gitster.g>
In-Reply-To: <DB4WQTRHWZN3.3VG20AZDK8VN@ddevault.org>

"Drew DeVault" <drew@ddevault.org> writes:

> Trailers and headers are different. The main point of the change-id
> discussion earlier on this list was to avoid adding trailers.

It sounds like this "avoiding trailers" is the root cause of the problem. If change-id is something not precious as you earlier said, having various operations lose it by design or by accident may not hurt a lot, but then doesn't it make it harder to notice by hiding it in a non-standard commit header field? There is no easy way to tell "git log --format" to show such a custom header, you'd need to tell amend, rebase, cherry-pick, etc. to carry the custom header forward (or not---have all the change-id loving communities agreed on when to propagate and when not to?).

Keeping it as one of the trailer fields will always make it available [*], propagate existing one by default with any existing tool, and because it is in the same place as log message, the user can easily remove it if it is not appropriate to keep it.

    Side note: [*] Unless you are doing "log --oneline", that is,
    but I'd say at that point you are hiding it deliberately.

> I also suspect that if we added this as an "inbody header" that older
> git implementations would ingest the X-Change-ID header into the commit
> message, which is not a desirable behavior.

Of course not. If the thing is a trailer, you do not even have to worry about such sillyness caused by adding it as a new in-body header.

> IMO the right way forward is to use a mail header.

No.  In the change-id case, trailer is the right way to go.

Having said all that, you may sense that I am not all that impressed by the previous rounds of dicsussions arguing for recording change-id as an extra non-standard commit header. We should think twice or more before making anything that structurally does not cause Git to behave differently taking advantage of the information recorded there an extra commit header field.

But after thinking thrice, we may find a set of good pieces of information that should be added as new commit header that are structurally more meaningful, and there will be times when we need to convey them over e-mailed workflow to allow patch recipient not to lose such information.

In such a case, I fully agree that embedding in an e-mail header would be the way to go.

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.