{"thread":{"id":"63733","subject":"[PATCH] pretty: add X-Change-ID to mail formats","startedAt":"2025-07-03T08:05:28Z","lastAt":"2025-07-03T11:32:46Z","messageCount":3,"participants":["Drew DeVault","Remo Senekowitsch"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"521236","messageId":"20250703074952.20737-1-drew@ddevault.org","threadId":"63733","inReplyTo":null,"subject":"[PATCH] pretty: add X-Change-ID to mail formats","fromName":"Drew DeVault","fromEmail":"drew@ddevault.org","sentAt":"2025-07-03T07:45:29Z","receivedAt":"2025-07-03T08:05:28Z","isPatch":true,"sender":{"key":"drew@ddevault.org","avatar":null},"body":"Introduce the X-Change-ID header to emails prepared by git (i.e. via\nformat-patch, send-email). This allows tools which work with those\nemails (e.g. patchwork, sourcehut) to meaningfully integrate with tools\nthat assign change IDs to commits.\n\nWith some follow-up work, this is also the first step towards ensuring\nthat those change IDs are preserved through from git-send-email to\ngit-am as a change moves through its review lifecycle.\n\nSigned-off-by: Drew DeVault <drew@ddevault.org>\n---\nI have refrained from implementing the git-am part of this work for now,\non the basis that I'm not sure how downstream tools like Jujutsu would\nfeel if git wrote the change-id header to new commits. Would that\nconflict with some internal deterministic process for coming up with the\nchange-id that could come up with a different answer, leading to\nconflicts? I don't know, so I would appreciate some insights from those\nwho understand the implications for their downstream systems.\n\nAdding the change ID to outgoing emails is useful on its own, however,\nso I think this patch is acceptable without the git-am side being\ninitially present.\n\n pretty.c | 7 ++++++-\n 1 file changed, 6 insertions(+), 1 deletion(-)\n\ndiff --git a/pretty.c b/pretty.c\nindex 0bc8ad8a9a..70fba7b023 100644\n--- a/pretty.c\n+++ b/pretty.c\n@@ -2045,7 +2045,7 @@ static void pp_header(struct pretty_print_context *pp,\n \tint parents_shown = 0;\n \n \tfor (;;) {\n-\t\tconst char *name, *line = *msg_p;\n+\t\tconst char *name, *change_id, *line = *msg_p;\n \t\tint linelen = get_one_line(*msg_p);\n \n \t\tif (!linelen)\n@@ -2089,6 +2089,11 @@ static void pp_header(struct pretty_print_context *pp,\n \t\t\tstrbuf_grow(sb, linelen + 80);\n \t\t\tpp_user_info(pp, \"Commit\", sb, name, encoding);\n \t\t}\n+\t\tif (skip_prefix(line, \"change-id \", &change_id) &&\n+\t\t    cmit_fmt_is_mail(pp->fmt)) {\n+\t\t\tstrbuf_addf(sb, \"X-Change-ID: %.*s\\n\",\n+\t\t\t\t    linelen - 11, change_id);\n+\t\t}\n \t}\n }\n \n-- \n2.50.0\n\n"},{"id":"521241","messageId":"DB2AARC4OKR3.48T4CC70KBUC@buenzli.dev","threadId":"63733","inReplyTo":"20250703074952.20737-1-drew@ddevault.org","subject":"Re: [PATCH] pretty: add X-Change-ID to mail formats","fromName":"Remo Senekowitsch","fromEmail":"remo@buenzli.dev","sentAt":"2025-07-03T08:41:06Z","receivedAt":"2025-07-03T08:41:18Z","isPatch":true,"sender":{"key":"remo@buenzli.dev","avatar":"https://gravatar.com/avatar/7df680b096206886db5a2dc983926f314985bbee662eb406cf23c65322cf98b7?d=mp&s=160"},"body":"Hi Drew,\n\nThank you, this is exciting!\n\nOn Thu Jul 3, 2025 at 9:45 AM CEST, Drew DeVault wrote:\n> I have refrained from implementing the git-am part of this work for now,\n> on the basis that I'm not sure how downstream tools like Jujutsu would\n> feel if git wrote the change-id header to new commits. Would that\n> conflict with some internal deterministic process for coming up with the\n> change-id that could come up with a different answer, leading to\n> conflicts?\n\nThis would be no problem at all. Jujutsu would very much welcome if Git\npreserved the change-id header, including for patches sent by email.\nJujutsu generates the initial change-id randomly and since any part of\nthe commit can change while the change-id remains stable, there is no\ndeterministic process that could be interfered with if Git wrote the\nchange-id header to new commits. So, there are no objections from my\nside to implementing the git-am part as well. :-)\n\nThis can kind of be tested already. Because Jujutsu already writes the\nchange-id header and sends it via git push, it must also be able to\nimport those headers from commits it hasn't seen before. Possible steps\nto verify this behavior:\n\n* Create a repo with Jujutsu, make some commits, push them to a remote.\n  (can be one on the local file system)\n\n* Clone this repo via Git.\n\n* (optional) Confirm with `git cat-file -p @` that the change-id header\n  was preserved.\n\n* Run `jj git init --colocate .` to upgrade the git repo to a jj repo.\n\n* Run `jj log` and observe that Jujutsu correctly imported the change-id\n  headers of existing commits it didn't know about previously.\n\nBest regards,\nRemo\n"},{"id":"521263","messageId":"DB2DY0C84G1R.3V7LEG87PHVTW@ddevault.org","threadId":"63733","inReplyTo":"DB2AARC4OKR3.48T4CC70KBUC@buenzli.dev","subject":"Re: [PATCH] pretty: add X-Change-ID to mail formats","fromName":"Drew DeVault","fromEmail":"drew@ddevault.org","sentAt":"2025-07-03T11:32:32Z","receivedAt":"2025-07-03T11:32:46Z","isPatch":true,"sender":{"key":"drew@ddevault.org","avatar":null},"body":"Sweet! I'm going to send a follow-up with git-am support.\n\nOn Thu Jul 3, 2025 at 10:41 AM CEST, Remo Senekowitsch wrote:\n> This can kind of be tested already. Because Jujutsu already writes the\n> change-id header and sends it via git push, it must also be able to\n> import those headers from commits it hasn't seen before. Possible steps\n> to verify this behavior:\n>\n> * Create a repo with Jujutsu, make some commits, push them to a remote.\n>   (can be one on the local file system)\n>\n> * Clone this repo via Git.\n>\n> * (optional) Confirm with `git cat-file -p @` that the change-id header\n>   was preserved.\n>\n> * Run `jj git init --colocate .` to upgrade the git repo to a jj repo.\n>\n> * Run `jj log` and observe that Jujutsu correctly imported the change-id\n>   headers of existing commits it didn't know about previously.\n\nI can confirm all of this works with the v2 I'm about to send, though I\nhave ascertained as much through a manual testing procedure that\nresembles your recommendation here.\n\nOne thing I'm less certain about is how to expand the tests in t/ to\ntest this behavior. I'll elaborate in the timely commentary of v2.\n"}]}