[PATCH] pretty: add X-Change-ID to mail formats

[PATCH] pretty: add X-Change-ID to mail formats

[Drew DeVault]

Introduce the X-Change-ID header to emails prepared by git (i.e. via
format-patch, send-email). This allows tools which work with those
emails (e.g. patchwork, sourcehut) to meaningfully integrate with tools
that assign change IDs to commits.

With some follow-up work, this is also the first step towards ensuring
that those change IDs are preserved through from git-send-email to
git-am as a change moves through its review lifecycle.

Signed-off-by: Drew DeVault <drew@ddevault.org>
---
I have refrained from implementing the git-am part of this work for now,
on the basis that I'm not sure how downstream tools like Jujutsu would
feel if git wrote the change-id header to new commits. Would that
conflict with some internal deterministic process for coming up with the
change-id that could come up with a different answer, leading to
conflicts? I don't know, so I would appreciate some insights from those
who understand the implications for their downstream systems.

Adding the change ID to outgoing emails is useful on its own, however,
so I think this patch is acceptable without the git-am side being
initially present.

 pretty.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/pretty.c b/pretty.c
index 0bc8ad8a9a..70fba7b023 100644
--- a/pretty.c
+++ b/pretty.c
@@ -2045,7 +2045,7 @@ static void pp_header(struct pretty_print_context *pp,
 	int parents_shown = 0;
 
 	for (;;) {
-		const char *name, *line = *msg_p;
+		const char *name, *change_id, *line = *msg_p;
 		int linelen = get_one_line(*msg_p);
 
 		if (!linelen)
@@ -2089,6 +2089,11 @@ static void pp_header(struct pretty_print_context *pp,
 			strbuf_grow(sb, linelen + 80);
 			pp_user_info(pp, "Commit", sb, name, encoding);
 		}
+		if (skip_prefix(line, "change-id ", &change_id) &&
+		    cmit_fmt_is_mail(pp->fmt)) {
+			strbuf_addf(sb, "X-Change-ID: %.*s\n",
+				    linelen - 11, change_id);
+		}
 	}
 }
 
-- 
2.50.0

Re: [PATCH] pretty: add X-Change-ID to mail formats

[Remo Senekowitsch]

Hi Drew,

Thank you, this is exciting!

On Thu Jul 3, 2025 at 9:45 AM CEST, Drew DeVault wrote:
> I have refrained from implementing the git-am part of this work for now,
> on the basis that I'm not sure how downstream tools like Jujutsu would
> feel if git wrote the change-id header to new commits. Would that
> conflict with some internal deterministic process for coming up with the
> change-id that could come up with a different answer, leading to
> conflicts?

This would be no problem at all. Jujutsu would very much welcome if Git
preserved the change-id header, including for patches sent by email.
Jujutsu generates the initial change-id randomly and since any part of
the commit can change while the change-id remains stable, there is no
deterministic process that could be interfered with if Git wrote the
change-id header to new commits. So, there are no objections from my
side to implementing the git-am part as well. :-)

This can kind of be tested already. Because Jujutsu already writes the
change-id header and sends it via git push, it must also be able to
import those headers from commits it hasn't seen before. Possible steps
to verify this behavior:

* Create a repo with Jujutsu, make some commits, push them to a remote.
  (can be one on the local file system)

* Clone this repo via Git.

* (optional) Confirm with `git cat-file -p @` that the change-id header
  was preserved.

* Run `jj git init --colocate .` to upgrade the git repo to a jj repo.

* Run `jj log` and observe that Jujutsu correctly imported the change-id
  headers of existing commits it didn't know about previously.

Best regards,
Remo

Re: [PATCH] pretty: add X-Change-ID to mail formats

[Drew DeVault]

[-- Attachment #1.1.1: Type: text/plain, Size: 1164 bytes --]

Sweet! I'm going to send a follow-up with git-am support.

On Thu Jul 3, 2025 at 10:41 AM CEST, Remo Senekowitsch wrote:
> This can kind of be tested already. Because Jujutsu already writes the
> change-id header and sends it via git push, it must also be able to
> import those headers from commits it hasn't seen before. Possible steps
> to verify this behavior:
>
> * Create a repo with Jujutsu, make some commits, push them to a remote.
>   (can be one on the local file system)
>
> * Clone this repo via Git.
>
> * (optional) Confirm with `git cat-file -p @` that the change-id header
>   was preserved.
>
> * Run `jj git init --colocate .` to upgrade the git repo to a jj repo.
>
> * Run `jj log` and observe that Jujutsu correctly imported the change-id
>   headers of existing commits it didn't know about previously.

I can confirm all of this works with the v2 I'm about to send, though I
have ascertained as much through a manual testing procedure that
resembles your recommendation here.

One thing I'm less certain about is how to expand the tests in t/ to
test this behavior. I'll elaborate in the timely commentary of v2.

[-- Attachment #1.2: 42F3F1862E3CC4B8.asc --]
[-- Type: application/pgp-keys, Size: 644 bytes --]

-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEZ7Y9kxYJKwYBBAHaRw8BAQdA/pPy6X+nNL5T2QaJKEM08xN/Kz7wFTAZoH5Y
riV9x1m0IERyZXcgRGVWYXVsdCA8ZHJld0BkZGV2YXVsdC5vcmc+iJMEExYKADsC
GwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AWIQSftec33CWynY7sRpFC8/GG
LjzEuAUCZ7Y9wwAKCRBC8/GGLjzEuMEEAP9DH+1LgvTqZDLZ8babB5Cdp5y0ZW+Q
Tx78mh1L8jJd6gEAssmgsImcrZv4adP2UW5RU5BHCe9KUdx0DyV83QwlFAS4OARn
tj2TEgorBgEEAZdVAQUBAQdAGAH9dlaCONoXpmQgHoQgYI2tS+VM3mzU8I2PyVYQ
1GUDAQgHiHgEGBYKACACGwwWIQSftec33CWynY7sRpFC8/GGLjzEuAUCZ7Y91gAK
CRBC8/GGLjzEuHcnAP4yjOiM0yqkST6yXzDUWze7B9Im24F8HVx+wNqcDaDtcAD/
fKQhz0SCPiblO6lc7MFUvlaOz2v87UpUYRhzPdgQqwk=
=emrb
-----END PGP PUBLIC KEY BLOCK-----

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]