{"thread":{"id":"64337","subject":"[PATCH 0/3] add a message-id header to git","startedAt":"2025-10-16T18:58:09Z","lastAt":"2025-10-16T22:41:11Z","messageCount":14,"participants":["James Bottomley","Kristoffer Haugsbakk","Junio C Hamano","brian m. carlson"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"528985","messageId":"20251016185758.21996-1-James.Bottomley@HansenPartnership.com","threadId":"64337","inReplyTo":null,"subject":"[PATCH 0/3] add a message-id header to git","fromName":"James Bottomley","fromEmail":"james.bottomley@hansenpartnership.com","sentAt":"2025-10-16T18:57:55Z","receivedAt":"2025-10-16T18:58:09Z","isPatch":true,"sender":{"key":"james.bottomley@hansenpartnership.com","avatar":"https://gravatar.com/avatar/5f93022e9a8d12d6779c93c6e7c14f455b4a0183229a0a5e6974b7fb7f8d7bcb?d=mp&s=160"},"body":"There has been some debate in the kernel community about how to link\ncommits back to email, which is the basis of a lot of scripting we do\n\nhttps://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/\n\nHowever, this problem is one that goes beyond the kernel, so having\ngit always track the message-id of the email used to create the commit\nwill be useful beyond our tools as well. The design of this\nmessage-id header is that it never shows up except in --pretty=raw\noutput, so it will never be ordinarily visible, but can be extracted\nby scripts. Some projects use the -m flag of git-am to add the\nMessage-Id to the trailers and for backwards compatibility, this\nfunctionality is not changed although it is hoped that it is now\nredundant.\n\nRegards,\n\nJames\n\n---\n\nJames Bottomley (3):\n mailinfo.c: always collect the message-id\n builtin/am.c: add a message-id commit header\n t4150-am: add a test for message-id header collection\n\n builtin/am.c | 15 ++++++++++++++-\n mailinfo.c | 5 ++---\n t/t4150-am.sh | 20 +++++++++++++++++++-\n 3 files changed, 35 insertions(+), 5 deletions(-)\n\n-- \n2.51.0\n\n"},{"id":"528986","messageId":"20251016185758.21996-2-James.Bottomley@HansenPartnership.com","threadId":"64337","inReplyTo":"20251016185758.21996-1-James.Bottomley@HansenPartnership.com","subject":"[PATCH 1/3] mailinfo.c: always collect the message-id","fromName":"James Bottomley","fromEmail":"james.bottomley@hansenpartnership.com","sentAt":"2025-10-16T18:57:56Z","receivedAt":"2025-10-16T18:58:44Z","isPatch":true,"sender":{"key":"james.bottomley@hansenpartnership.com","avatar":"https://gravatar.com/avatar/5f93022e9a8d12d6779c93c6e7c14f455b4a0183229a0a5e6974b7fb7f8d7bcb?d=mp&s=160"},"body":"Prior to this mailinfo only collected the message-id if\nadd_messsage_id was true. Now git-am needs the message-id all the\ntime, hence the change, and anything checking to see if message-id\nshould be included in the trailer must check both any_message_id and\nmessage_id.\n\nSigned-off-by: James Bottomley \n---\n mailinfo.c | 5 ++---\n 1 file changed, 2 insertions(+), 3 deletions(-)\n\ndiff --git a/mailinfo.c b/mailinfo.c\nindex 99ac596e09..62a30e37b1 100644\n--- a/mailinfo.c\n+++ b/mailinfo.c\n@@ -609,8 +609,7 @@ static int check_header(struct mailinfo *mi,\n \t\tgoto check_header_out;\n \t}\n \tif (parse_header(line, \"Message-ID\", mi, &sb)) {\n-\t\tif (mi->add_message_id)\n-\t\t\tmi->message_id = strbuf_detach(&sb, NULL);\n+\t\tmi->message_id = strbuf_detach(&sb, NULL);\n \t\tret = 1;\n \t\tgoto check_header_out;\n \t}\n@@ -837,7 +836,7 @@ static int handle_commit_msg(struct mailinfo *mi, struct strbuf *line)\n \t}\n \n \tif (patchbreak(line)) {\n-\t\tif (mi->message_id)\n+\t\tif (mi->add_message_id && mi->message_id)\n \t\t\tstrbuf_addf(&mi->log_message,\n \t\t\t\t \"Message-ID: %s\\n\", mi->message_id);\n \t\treturn 1;\n-- \n2.51.0\n\n"},{"id":"528987","messageId":"20251016185758.21996-3-James.Bottomley@HansenPartnership.com","threadId":"64337","inReplyTo":"20251016185758.21996-1-James.Bottomley@HansenPartnership.com","subject":"[PATCH 2/3] builtin/am.c: add a message-id commit header","fromName":"James Bottomley","fromEmail":"james.bottomley@hansenpartnership.com","sentAt":"2025-10-16T18:57:57Z","receivedAt":"2025-10-16T18:59:15Z","isPatch":true,"sender":{"key":"james.bottomley@hansenpartnership.com","avatar":"https://gravatar.com/avatar/5f93022e9a8d12d6779c93c6e7c14f455b4a0183229a0a5e6974b7fb7f8d7bcb?d=mp&s=160"},"body":"Now that mailinfo is updated to collect the message_id all the time,\nuse this in do_commit to add a \"message-id\" extra header containing\nthe message_id if it exists. This means that git am will always\nrecord the message-id if it can be found in the commit. It will still\nadd it to the trailer if -m is specified, keeping the behaviour\nbackwards compatible.\n\nSigned-off-by: James Bottomley \n---\n builtin/am.c | 15 ++++++++++++++-\n 1 file changed, 14 insertions(+), 1 deletion(-)\n\ndiff --git a/builtin/am.c b/builtin/am.c\nindex 277c2e7937..ab05701a8d 100644\n--- a/builtin/am.c\n+++ b/builtin/am.c\n@@ -119,6 +119,7 @@ struct am_state {\n \tchar *author_name;\n \tchar *author_email;\n \tchar *author_date;\n+\tchar *msg_id;\n \tchar *msg;\n \tsize_t msg_len;\n \n@@ -187,6 +188,7 @@ static void am_state_release(struct am_state *state)\n \tfree(state->author_email);\n \tfree(state->author_date);\n \tfree(state->msg);\n+\tfree(state->msg_id);\n \tstrvec_clear(&state->git_apply_opts);\n }\n \n@@ -1313,6 +1315,9 @@ static int parse_mail(struct am_state *state, const char *mail)\n \tassert(!state->msg);\n \tstate->msg = strbuf_detach(&msg, &state->msg_len);\n \n+\tassert(!state->msg_id);\n+\tstate->msg_id = xstrdup_or_null(mi.message_id);\n+\n finish:\n \tstrbuf_release(&msg);\n \tstrbuf_release(&author_date);\n@@ -1668,6 +1673,7 @@ static void do_commit(const struct am_state *state)\n \tstruct commit_list *parents = NULL;\n \tconst char *reflog_msg, *author, *committer = NULL;\n \tstruct strbuf sb = STRBUF_INIT;\n+\tstruct commit_extra_header *extra = NULL;\n \n \tif (!state->no_verify && run_hooks(the_repository, \"pre-applypatch\"))\n \t\texit(1);\n@@ -1699,9 +1705,16 @@ static void do_commit(const struct am_state *state)\n \t\t\t\t\t\t\t : state->author_date,\n \t\t\t\t IDENT_STRICT);\n \n+\tif (state->msg_id) {\n+\t\tCALLOC_ARRAY(extra, 1);\n+\t\textra->key = xstrdup(\"message-id\");\n+\t\textra->value = xstrdup(state->msg_id);\n+\t\textra->len = strlen(extra->value);\n+\t}\n+\n \tif (commit_tree_extended(state->msg, state->msg_len, &tree, parents,\n \t\t\t\t &commit, author, committer, state->sign_commit,\n-\t\t\t\t NULL))\n+\t\t\t\t extra))\n \t\tdie(_(\"failed to write commit object\"));\n \n \treflog_msg = getenv(\"GIT_REFLOG_ACTION\");\n-- \n2.51.0\n\n"},{"id":"528988","messageId":"20251016185758.21996-4-James.Bottomley@HansenPartnership.com","threadId":"64337","inReplyTo":"20251016185758.21996-1-James.Bottomley@HansenPartnership.com","subject":"[PATCH 3/3] t4150-am: add a test for message-id header collection","fromName":"James Bottomley","fromEmail":"james.bottomley@hansenpartnership.com","sentAt":"2025-10-16T18:57:58Z","receivedAt":"2025-10-16T18:59:37Z","isPatch":true,"sender":{"key":"james.bottomley@hansenpartnership.com","avatar":"https://gravatar.com/avatar/5f93022e9a8d12d6779c93c6e7c14f455b4a0183229a0a5e6974b7fb7f8d7bcb?d=mp&s=160"},"body":"Since git am now always adds the message-id header, fix test 'am\napplies patch e-mail not in a mbox' not to add the header because\notherwise the commit won't be equivalent to second and add a new test\nthat the message-id header gets correctly added.\n\nSigned-off-by: James Bottomley \n---\n t/t4150-am.sh | 20 +++++++++++++++++++-\n 1 file changed, 19 insertions(+), 1 deletion(-)\n\ndiff --git a/t/t4150-am.sh b/t/t4150-am.sh\nindex 699a81ab5c..82603b2bbf 100755\n--- a/t/t4150-am.sh\n+++ b/t/t4150-am.sh\n@@ -109,6 +109,12 @@ test_expect_success setup '\n \t\techo \"X-Fake-Field: Line Three\" &&\n \t\tgit format-patch --stdout first | sed -e \"1d\"\n \t} > patch1.eml &&\n+\t{\n+\t\techo \"X-Fake-Field: Line One\" &&\n+\t\techo \"X-Fake-Field: Line Two\" &&\n+\t\techo \"X-Fake-Field: Line Three\" &&\n+\t\tgit format-patch --stdout first | sed -e \"1d\"\n+\t} > patch1-nomsgid.eml &&\n \t{\n \t\techo \"X-Fake-Field: Line One\" &&\n \t\techo \"X-Fake-Field: Line Two\" &&\n@@ -235,13 +241,25 @@ test_expect_success 'am applies patch e-mail not in a mbox' '\n \trm -fr .git/rebase-apply &&\n \tgit reset --hard &&\n \tgit checkout first &&\n-\tgit am patch1.eml &&\n+\tgit am patch1-nomsgid.eml &&\n \ttest_path_is_missing .git/rebase-apply &&\n \tgit diff --exit-code second &&\n \ttest \"$(git rev-parse second)\" = \"$(git rev-parse HEAD)\" &&\n \ttest \"$(git rev-parse second^)\" = \"$(git rev-parse HEAD^)\"\n '\n \n+test_expect_success 'am adds message-id to the header' '\n+\trm -fr .git/rebase-apply &&\n+\tgit reset --hard &&\n+\tgit checkout first &&\n+\tgit am patch1.eml &&\n+\ttest_path_is_missing .git/rebase-apply &&\n+\tgit diff --exit-code second &&\n+\ttest \"$(git rev-parse second)\" != \"$(git rev-parse HEAD)\" &&\n+\ttest \"$(git rev-parse second^)\" = \"$(git rev-parse HEAD^)\" &&\n+\tgit show --pretty=raw HEAD | grep \"^message-id <1226501681-24923-1-git-send-email-bda@mnsspb.ru>\"\n+'\n+\n test_expect_success 'am applies patch e-mail not in a mbox with CRLF' '\n \trm -fr .git/rebase-apply &&\n \tgit reset --hard &&\n-- \n2.51.0\n\n"},{"id":"528991","messageId":"6fd0ac40-6cf8-436a-af73-1159f6569efd@app.fastmail.com","threadId":"64337","inReplyTo":"20251016185758.21996-1-James.Bottomley@HansenPartnership.com","subject":"Re: [PATCH 0/3] add a message-id header to git","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-16T19:26:43Z","receivedAt":"2025-10-16T19:27:43Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 16, 2025, at 20:57, James Bottomley wrote:\n> There has been some debate in the kernel community about how to link\n> commits back to email, which is the basis of a lot of scripting we do\n>\n> https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/\n>\n> However, this problem is one that goes beyond the kernel, so having\n> git always track the message-id of the email used to create the commit\n> will be useful beyond our tools as well. The design of this\n> message-id header is that it never shows up except in --pretty=raw\n> output, so it will never be ordinarily visible, but can be extracted\n> by scripts. Some projects use the -m flag of git-am to add the\n> Message-Id to the trailers and for backwards compatibility, this\n> functionality is not changed although it is hoped that it is now\n> redundant.\n\nRelated discussions: “Change-ID”:\n\nhttps://lore.kernel.org/git/aOQWWkj%2Fq7GfKZY7@nand.local/\n\nhttps://lore.kernel.org/git/20250703074952.20737-1-drew@ddevault.org/\n\nhttps://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf1Aa5gPr0FXzdcywqUUw@mail.gmail.com/\n\nInspired by Gerrit, Git Butler, Jujutsu, according to the last link.\n"},{"id":"529003","messageId":"5e056d3cee9453079d4251009ecd57b208285ae0.camel@HansenPartnership.com","threadId":"64337","inReplyTo":"6fd0ac40-6cf8-436a-af73-1159f6569efd@app.fastmail.com","subject":"Re: [PATCH 0/3] add a message-id header to git","fromName":"James Bottomley","fromEmail":"james.bottomley@hansenpartnership.com","sentAt":"2025-10-16T20:10:11Z","receivedAt":"2025-10-16T20:10:13Z","isPatch":true,"sender":{"key":"james.bottomley@hansenpartnership.com","avatar":"https://gravatar.com/avatar/5f93022e9a8d12d6779c93c6e7c14f455b4a0183229a0a5e6974b7fb7f8d7bcb?d=mp&s=160"},"body":"On Thu, 2025-10-16 at 21:26 +0200, Kristoffer Haugsbakk wrote:\n> On Thu, Oct 16, 2025, at 20:57, James Bottomley wrote:\n> > There has been some debate in the kernel community about how to\n> > link\n> > commits back to email, which is the basis of a lot of scripting we\n> > do\n> > \n> > https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/\n> > \n> > However, this problem is one that goes beyond the kernel, so having\n> > git always track the message-id of the email used to create the\n> > commit\n> > will be useful beyond our tools as well.  The design of this\n> > message-id header is that it never shows up except in --pretty=raw\n> > output, so it will never be ordinarily visible, but can be\n> > extracted\n> > by scripts.  Some projects use the -m flag of git-am to add the\n> > Message-Id to the trailers and for backwards compatibility, this\n> > functionality is not changed although it is hoped that it is now\n> > redundant.\n> \n> Related discussions: “Change-ID”:\n> \n> https://lore.kernel.org/git/aOQWWkj%2Fq7GfKZY7@nand.local/\n> \n> https://lore.kernel.org/git/20250703074952.20737-1-drew@ddevault.org/\n> \n> https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf1Aa5gPr0FXzdcywqUUw@mail.gmail.com/\n> \n> Inspired by Gerrit, Git Butler, Jujutsu, according to the last link.\n\nSo this is a different beast from change-id. Change-id is used to\ntrack the same change across different commits in a fully git based\nworkflow ... and in that workflow a message-id wouldn't exist because\nthere's really no email based interaction. The reason email projects\nneed the message-id is so that all of the ci type tooling we have can\nlink a commit back to the email it came from (so tip bots use it to\nreply when the commit is accepted and things). In an email based\nworkflow there's not really such a thing as a global change-id and so\nthe two proposals are pretty orthogonal.\n\nRegards,\n\nJames\n\n"},{"id":"529005","messageId":"2a77313d-a4cb-42bc-8cc3-2811869bae13@app.fastmail.com","threadId":"64337","inReplyTo":"5e056d3cee9453079d4251009ecd57b208285ae0.camel@HansenPartnership.com","subject":"Re: [PATCH 0/3] add a message-id header to git","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-16T20:31:05Z","receivedAt":"2025-10-16T20:31:28Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 16, 2025, at 22:10, James Bottomley wrote:\n> On Thu, 2025-10-16 at 21:26 +0200, Kristoffer Haugsbakk wrote:\n>> On Thu, Oct 16, 2025, at 20:57, James Bottomley wrote:\n>> > There has been some debate in the kernel community about how to\n>> > link\n>> > commits back to email, which is the basis of a lot of scripting we\n>> > do\n>> >\n>> > https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/\n>> >[snip]\n>>\n>> Related discussions: “Change-ID”:\n>>\n>>[snip]\n>\n> So this is a different beast from change-id. Change-id is used to\n> track the same change across different commits in a fully git based\n> workflow ... and in that workflow a message-id wouldn't exist because\n> there's really no email based interaction. The reason email projects\n> need the message-id is so that all of the ci type tooling we have can\n> link a commit back to the email it came from (so tip bots use it to\n> reply when the commit is accepted and things). In an email based\n> workflow there's not really such a thing as a global change-id and so\n> the two proposals are pretty orthogonal.\n\nThey are not related in the sense that they mean the same thing. They\nare related in the sense that parts of the discussion is about using a\ncommit header to implement the idea.\n\nThanks\n"},{"id":"529006","messageId":"xmqqfrbi37v6.fsf@gitster.g","threadId":"64337","inReplyTo":"20251016185758.21996-1-James.Bottomley@HansenPartnership.com","subject":"Re: [PATCH 0/3] add a message-id header to git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-16T20:32:45Z","receivedAt":"2025-10-16T20:32:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"James Bottomley writes:\n\n> There has been some debate in the kernel community about how to link\n> commits back to email, which is the basis of a lot of scripting we do\n>\n> https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/\n>\n> However, this problem is one that goes beyond the kernel, so having\n> git always track the message-id of the email used to create the commit\n> will be useful beyond our tools as well. The design of this\n> message-id header is that it never shows up except in --pretty=raw\n> output, so it will never be ordinarily visible, but can be extracted\n> by scripts. Some projects use the -m flag of git-am to add the\n> Message-Id to the trailers and for backwards compatibility, this\n> functionality is not changed although it is hoped that it is now\n> redundant.\n\nI am perfectly fine with mailinfo changes and it is OK to add it to\ncommit trailer, but to the commit object header? Having to maintain\nan extra header is a headache, in that you have to worry about what\nrebases and cherry-picks would do to them. Please don't.\n\nI haven't carefully read [2/3] yet, but do we now forbid to run the\npoor-man's rebase \"git format-patch ... | git am\" pipeline by\ninsisting that state->msg_id to exist in parse_mail()? The output\nof format-patch over existing commits may not have the message-id\nheaders.\n\n\n\n"},{"id":"529016","messageId":"7205e71da08f22db757b5dc0bcf3fef27db40ea4.camel@HansenPartnership.com","threadId":"64337","inReplyTo":"xmqqfrbi37v6.fsf@gitster.g","subject":"Re: [PATCH 0/3] add a message-id header to git","fromName":"James Bottomley","fromEmail":"james.bottomley@hansenpartnership.com","sentAt":"2025-10-16T21:00:40Z","receivedAt":"2025-10-16T21:00:41Z","isPatch":true,"sender":{"key":"james.bottomley@hansenpartnership.com","avatar":"https://gravatar.com/avatar/5f93022e9a8d12d6779c93c6e7c14f455b4a0183229a0a5e6974b7fb7f8d7bcb?d=mp&s=160"},"body":"On Thu, 2025-10-16 at 13:32 -0700, Junio C Hamano wrote:\n> James Bottomley writes:\n> \n> > There has been some debate in the kernel community about how to\n> > link commits back to email, which is the basis of a lot of\n> > scripting we do\n> > \n> > https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/\n> > \n> > However, this problem is one that goes beyond the kernel, so having\n> > git always track the message-id of the email used to create the\n> > commit will be useful beyond our tools as well.  The design of this\n> > message-id header is that it never shows up except in --pretty=raw\n> > output, so it will never be ordinarily visible, but can be\n> > extracted by scripts.  Some projects use the -m flag of git-am to\n> > add the Message-Id to the trailers and for backwards compatibility,\n> > this functionality is not changed although it is hoped that it is\n> > now redundant.\n> \n> I am perfectly fine with mailinfo changes and it is OK to add it to\n> commit trailer, but to the commit object header?  Having to maintain\n> an extra header is a headache, in that you have to worry about what\n> rebases and cherry-picks would do to them.  Please don't.\n\nMy assumption was that any extra headers in the git object get carried\nover, but if I need to do something to make that happen, then I can\ncertainly craft patches.\n\nThe reason for doing it as a header is just for it to be always there\nfor email workflow. The trailer doesn't have the same property because\npeople forget to add it and Linus hates it and refuses to allow it in\nkernel code. I'm hoping the ubiquity will make up for the pain of\nadding another header.\n\n> I haven't carefully read [2/3] yet, but do we now forbid to run the\n> poor-man's rebase \"git format-patch ... | git am\" pipeline by\n> insisting that state->msg_id to exist in parse_mail()?  The output\n> of format-patch over existing commits may not have the message-id\n> headers.\n\nSo this one's a bit more deliberate. If you import email and then re-\nsend as email we can't keep the same message-id; the internet RFCs\nrequire us to keep message-ids unique, so git-format-patch won't output\nthe message-id. That necessarily also means that the poor man's rebase\nyou cite above will still run, but it would drop the message-id header.\n\nRegards,\n\nJames\n\n"},{"id":"529021","messageId":"xmqqqzv21r76.fsf@gitster.g","threadId":"64337","inReplyTo":"7205e71da08f22db757b5dc0bcf3fef27db40ea4.camel@HansenPartnership.com","subject":"Re: [PATCH 0/3] add a message-id header to git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-16T21:18:05Z","receivedAt":"2025-10-16T21:18:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"James Bottomley writes:\n\n> So this one's a bit more deliberate. If you import email and then re-\n> send as email we can't keep the same message-id; the internet RFCs\n> require us to keep message-ids unique, so git-format-patch won't output\n> the message-id. That necessarily also means that the poor man's rebase\n> you cite above will still run, but it would drop the message-id header.\n\nThat is one more reason why I do not want it in the header, or \"-m\"\nto overwrite existing message-id trailer. If I received a patch via\na message, applied, and forwarded it out of a commit I previously\ncreated from a message I earlier received from elsewhere, I would\nwant the recipient of my forwarded patch message to be able to link\nthe message I forward with the original message, probably in the\nmailing list archive where I took the message from in the first\nplace.\n\n"},{"id":"529022","messageId":"ef34b2cf-e867-44e7-8c62-682f64f2fb0a@app.fastmail.com","threadId":"64337","inReplyTo":"xmqqqzv21r76.fsf@gitster.g","subject":"Re: [PATCH 0/3] add a message-id header to git","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-16T21:28:55Z","receivedAt":"2025-10-16T21:29:16Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 16, 2025, at 23:18, Junio C Hamano wrote:\n> James Bottomley writes:\n>\n>> So this one's a bit more deliberate. If you import email and then re-\n>> send as email we can't keep the same message-id; the internet RFCs\n>> require us to keep message-ids unique, so git-format-patch won't output\n>> the message-id. That necessarily also means that the poor man's rebase\n>> you cite above will still run, but it would drop the message-id header.\n>\n> That is one more reason why I do not want it in the header, or \"-m\"\n> to overwrite existing message-id trailer. If I received a patch via\n> a message, applied, and forwarded it out of a commit I previously\n> created from a message I earlier received from elsewhere, I would\n> want the recipient of my forwarded patch message to be able to link\n> the message I forward with the original message, probably in the\n> mailing list archive where I took the message from in the first\n> place.\n\nX-Git-Original-Message-ID: ?\n\n-- \nKristoffer Haugsbakk\n\n"},{"id":"529026","messageId":"2464e11c-32b4-4372-90b4-9a6302390e3d@app.fastmail.com","threadId":"64337","inReplyTo":"20251016185758.21996-1-James.Bottomley@HansenPartnership.com","subject":"Re: [PATCH 0/3] add a message-id header to git","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-16T21:50:25Z","receivedAt":"2025-10-16T21:50:46Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 16, 2025, at 20:57, James Bottomley wrote:\n> There has been some debate in the kernel community about how to link\n> commits back to email, which is the basis of a lot of scripting we do\n>\n> https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/\n\nIn that email:\n\nJB> There has been a lot of discussion on the tooling list about how the\nJB> loss of link trailers has updated both tooling and triaging issues.\n\nI know of a recent[1] negative opinion about `Link`:\n\nLT> It's not that it isn't \"useful to me\". It's that it HURTS, and it's\nLT> entirely redundant.\nLT>\nLT> It literally wastes my time. Yes, I have the option to ignore them,\nLT> but then I ignore potentially *good* links.\n\nBut has there been a decision that they are going away? Do you have a\nlink to that discussion? Just curious to know more. :)\n\n[1]: https://lore.kernel.org/all/CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com/\n\nYou might know that the Git project tracks Message-ID for all commits in\n`refs/notes/amlog`. This is straightforward when only the maintainer\napplies emails. And up until three hours ago I thought it couldn’t work\nbeyond on person.\n\nBut maybe it could?\n\n1. Everyone who wants to makes or shares a hook to add the Message-ID\n2. (and maybe try to upstream a built-in way; this would be simpler to\n upstream than a new commit header)\n3. Push out the notes ref along with all the other refs\n4. The tooling (programs) fetch and merge all of them (from the repos\n they know about)\n5. With only a collection of remotes that run a hook to add a line to\n each incoming commit: the tools can merge all repos since people will\n not apply a patch and get a hash collision with someone somewhere\n else\n6. (“the tools” here since you seem to focus on CI or general tooling)\n7. Consumers can fetch this note and have all known mappings\n\nWould this work among nice, cooperating individuals? (That don’t try to\nconfuse the tooling by notes for commits that already exist in other\nrepos. For some reason.)\n\nA more careful/structured implementation could also check that the\nincoming notes are all (1) only additions, (2) one-line notes, (3) only\nannotate commits that the notes-committer has committed (note committer\nand commit committer are the same...). But I guess for (3) to be\nmeaningful you have to manually map repositories to committers.\nE.g. repository for Bob may only annotate commits by himself. Or you\ncan sign the note commits if that is necessary.\n\nRelated sub-discussion on the linked thread:\n\nhttps://lore.kernel.org/ksummit/68ee73dcd10ee_2f89910075@dwillia2-mobl4.notmuch/\n\nOn the one hand, pushing and fetching notes does not necessarily sound\nlike it would fit in an email workflow (*too* integrated with git(1)?).\nBut your reply here does not mention that kind of objection so I will\nsoldier on:\n\nhttps://lore.kernel.org/ksummit/146639e2bc8b5327f57e4297f5a0fcfd3c86d95c.camel@HansenPartnership.com/\n\nJB> I think part of the problem with notes is they're designed not to be\nJB> shared.\n\nThey aren’t designed to not to be shared, but you are getting at a real\nusability downside for individuals. They are “designed” to be hard to\nconsume/fetch in setups where every single user needs to set up a\nrefspec in order to fetch them for them to be useful.\n\nBut you seem to focus on tooling. For tooling they shouldn’t be any\nharder to set up than anything else.\n\nSo yeah the downside is for individuals who just want to be able to\nopt-in to pretty-print the Message-IDs; they would have to set up a\nrefspec to get the Message-IDs, just like they do here in Git.\n\nThey don’t get it for free from the Git commit object itself.\n\nJB> So there are lots of diverse internal uses for notes that\nJB> aren't just the annotations you're thinking of here, so when I push to\nJB> a notes tree, I'd likely have to filter and when I pull from it I\nJB> wouldn't necessarily want everyone else's notes ... it's like when you\nJB> forget to add --no-tags to a pull from someone else's tree and you get\nJB> a load of their internal tags that contaminates your internal tag pool.\n\nYou get all the blobs for the notes. They take up disk space but they\ndon’t pollute things beyond that.\n\nJB> Yes, but not all subsystems would care about everything even in this\nJB> notes driven annotations model ... so you either have to have filter on\nJB> pull or strict rules about what goes in, which then causes issues with\nJB> local notes uses.\n\nWith one blessed notes namespace for Message-IDs, where’s the potential\nconflict? Those who care can fetch.\n\nSee previous paragraphs about merging notes across repositories.\n\nWith all that naively said: note objections by Konstantin Ryabitsev.\n\nhttps://lore.kernel.org/ksummit/20251015-versed-active-silkworm-bb87bd@lemur/\n\n>\n> However, this problem is one that goes beyond the kernel, so having\n\nAre there examples of projects where this is a pressing need? I would\nimagine it is not for smaller email-based projects.\n\nI’m asking because it is good to be specific in the cover letter for a\nmajor change. More than just stating that other cases exist.\n\n>[snip]\n"},{"id":"529030","messageId":"xmqqms5q1ok6.fsf@gitster.g","threadId":"64337","inReplyTo":"2464e11c-32b4-4372-90b4-9a6302390e3d@app.fastmail.com","subject":"Re: [PATCH 0/3] add a message-id header to git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-16T22:15:05Z","receivedAt":"2025-10-16T22:15:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kristoffer Haugsbakk\" writes:\n\n> But has there been a decision that they are going away? Do you have a\n> link to that discussion? Just curious to know more. :)\n>\n> [1]: https://lore.kernel.org/all/CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com/\n\nI think the latest is:\n\nhttps://lore.kernel.org/all/CAHk-=wj5MATvT-FR8qNpXuuBGiJdjY1kRfhtzuyBSpTKR+=Vtw@mail.gmail.com/\n\nregarding the \"Link:\" thing.\n"},{"id":"529031","messageId":"aPF0fmxsPQvxHfCu@fruit.crustytoothpaste.net","threadId":"64337","inReplyTo":"20251016185758.21996-3-James.Bottomley@HansenPartnership.com","subject":"Re: [PATCH 2/3] builtin/am.c: add a message-id commit header","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-10-16T22:41:02Z","receivedAt":"2025-10-16T22:41:11Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-10-16 at 18:57:57, James Bottomley wrote:\n> Now that mailinfo is updated to collect the message_id all the time,\n> use this in do_commit to add a \"message-id\" extra header containing\n> the message_id if it exists. This means that git am will always\n> record the message-id if it can be found in the commit. It will still\n> add it to the trailer if -m is specified, keeping the behaviour\n> backwards compatible.\n\nThis has most of the same downsides as the change ID header.\n\nYes, Message-IDs have to be globally unique, but sometimes they're not\ndue to implementation bugs. It also allows tracking of changes which\nmay be a problem for privacy reasons, especially when it's always\nenabled. It's also a side channel where people can exfiltrate\ninformation (e.g., cryptographic keys) without much visibility.\n\nIn addition, it is not guaranteed that message IDs are suitable for\ninclusion. They may be missing, malformed, or contain unacceptable\ncontent (profanities, discriminatory content, EICAR test virus,\netc.)[0][1]. Silently inserting them into every commit without user\nintervention, especially without a corresponding fsck check, is not a\ngood idea. Commit messages, author lines, and committer lines are at\nleast reasonably visible to the person applying the patch, but many mail\nclients don't show the message ID by default or at all.\n\n[0] You may think this is not a problem, but someone will do these\nthings if they can, possibly in a major project, because people are\ninventive at causing chaos and we need to provide them fewer easy ways\nto do so. People already intentionally sow discord by pushing commits\nwith timestamps beyond 2^63, or even under 2^63 but beyond the expected\nlifespan of our solar system, which then causes havoc when languages\nlike Ruby try to parse and interpret them.\n[1] For instance, one of my servers is named \"castro\" (as in the San\nFrancisco neigbourhood, the Castro), but people, upon hearing the name,\nare usually horrified to think that I've named my server for the Cuban\nleader. That name has ended up in many, many message IDs over the\nyears, and I know of still other much less savoury hostnames people have\nused which will also necessarily appear in message IDs.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"}]}