[PATCH 0/3] add a message-id header to git

[PATCH 0/3] add a message-id header to git

[James Bottomley]

There has been some debate in the kernel community about how to link
commits back to email, which is the basis of a lot of scripting we do

https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/

However, this problem is one that goes beyond the kernel, so having
git always track the message-id of the email used to create the commit
will be useful beyond our tools as well.  The design of this
message-id header is that it never shows up except in --pretty=raw
output, so it will never be ordinarily visible, but can be extracted
by scripts.  Some projects use the -m flag of git-am to add the
Message-Id to the trailers and for backwards compatibility, this
functionality is not changed although it is hoped that it is now
redundant.

Regards,

James

---

James Bottomley (3):
  mailinfo.c: always collect the message-id
  builtin/am.c: add a message-id commit header
  t4150-am: add a test for message-id header collection

 builtin/am.c  | 15 ++++++++++++++-
 mailinfo.c    |  5 ++---
 t/t4150-am.sh | 20 +++++++++++++++++++-
 3 files changed, 35 insertions(+), 5 deletions(-)

-- 
2.51.0

[PATCH 1/3] mailinfo.c: always collect the message-id

[James Bottomley]

Prior to this mailinfo only collected the message-id if
add_messsage_id was true. Now git-am needs the message-id all the
time, hence the change, and anything checking to see if message-id
should be included in the trailer must check both any_message_id and
message_id.

Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
---
 mailinfo.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/mailinfo.c b/mailinfo.c
index 99ac596e09..62a30e37b1 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -609,8 +609,7 @@ static int check_header(struct mailinfo *mi,
 		goto check_header_out;
 	}
 	if (parse_header(line, "Message-ID", mi, &sb)) {
-		if (mi->add_message_id)
-			mi->message_id = strbuf_detach(&sb, NULL);
+		mi->message_id = strbuf_detach(&sb, NULL);
 		ret = 1;
 		goto check_header_out;
 	}
@@ -837,7 +836,7 @@ static int handle_commit_msg(struct mailinfo *mi, struct strbuf *line)
 	}
 
 	if (patchbreak(line)) {
-		if (mi->message_id)
+		if (mi->add_message_id && mi->message_id)
 			strbuf_addf(&mi->log_message,
 				    "Message-ID: %s\n", mi->message_id);
 		return 1;
-- 
2.51.0

[PATCH 2/3] builtin/am.c: add a message-id commit header

[James Bottomley]

Now that mailinfo is updated to collect the message_id all the time,
use this in do_commit to add a "message-id" extra header containing
the message_id if it exists.  This means that git am will always
record the message-id if it can be found in the commit.  It will still
add it to the trailer if -m is specified, keeping the behaviour
backwards compatible.

Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
---
 builtin/am.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/builtin/am.c b/builtin/am.c
index 277c2e7937..ab05701a8d 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -119,6 +119,7 @@ struct am_state {
 	char *author_name;
 	char *author_email;
 	char *author_date;
+	char *msg_id;
 	char *msg;
 	size_t msg_len;
 
@@ -187,6 +188,7 @@ static void am_state_release(struct am_state *state)
 	free(state->author_email);
 	free(state->author_date);
 	free(state->msg);
+	free(state->msg_id);
 	strvec_clear(&state->git_apply_opts);
 }
 
@@ -1313,6 +1315,9 @@ static int parse_mail(struct am_state *state, const char *mail)
 	assert(!state->msg);
 	state->msg = strbuf_detach(&msg, &state->msg_len);
 
+	assert(!state->msg_id);
+	state->msg_id = xstrdup_or_null(mi.message_id);
+
 finish:
 	strbuf_release(&msg);
 	strbuf_release(&author_date);
@@ -1668,6 +1673,7 @@ static void do_commit(const struct am_state *state)
 	struct commit_list *parents = NULL;
 	const char *reflog_msg, *author, *committer = NULL;
 	struct strbuf sb = STRBUF_INIT;
+	struct commit_extra_header *extra = NULL;
 
 	if (!state->no_verify && run_hooks(the_repository, "pre-applypatch"))
 		exit(1);
@@ -1699,9 +1705,16 @@ static void do_commit(const struct am_state *state)
 							 : state->author_date,
 				      IDENT_STRICT);
 
+	if (state->msg_id) {
+		CALLOC_ARRAY(extra, 1);
+		extra->key = xstrdup("message-id");
+		extra->value = xstrdup(state->msg_id);
+		extra->len = strlen(extra->value);
+	}
+
 	if (commit_tree_extended(state->msg, state->msg_len, &tree, parents,
 				 &commit, author, committer, state->sign_commit,
-				 NULL))
+				 extra))
 		die(_("failed to write commit object"));
 
 	reflog_msg = getenv("GIT_REFLOG_ACTION");
-- 
2.51.0

Re: [PATCH 2/3] builtin/am.c: add a message-id commit header

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

On 2025-10-16 at 18:57:57, James Bottomley wrote:
> Now that mailinfo is updated to collect the message_id all the time,
> use this in do_commit to add a "message-id" extra header containing
> the message_id if it exists.  This means that git am will always
> record the message-id if it can be found in the commit.  It will still
> add it to the trailer if -m is specified, keeping the behaviour
> backwards compatible.

This has most of the same downsides as the change ID header.

Yes, Message-IDs have to be globally unique, but sometimes they're not
due to implementation bugs.  It also allows tracking of changes which
may be a problem for privacy reasons, especially when it's always
enabled.  It's also a side channel where people can exfiltrate
information (e.g., cryptographic keys) without much visibility.

In addition, it is not guaranteed that message IDs are suitable for
inclusion.  They may be missing, malformed, or contain unacceptable
content (profanities, discriminatory content, EICAR test virus,
etc.)[0][1]. Silently inserting them into every commit without user
intervention, especially without a corresponding fsck check, is not a
good idea. Commit messages, author lines, and committer lines are at
least reasonably visible to the person applying the patch, but many mail
clients don't show the message ID by default or at all.

[0] You may think this is not a problem, but someone will do these
things if they can, possibly in a major project, because people are
inventive at causing chaos and we need to provide them fewer easy ways
to do so.  People already intentionally sow discord by pushing commits
with timestamps beyond 2^63, or even under 2^63 but beyond the expected
lifespan of our solar system, which then causes havoc when languages
like Ruby try to parse and interpret them.
[1] For instance, one of my servers is named "castro" (as in the San
Francisco neigbourhood, the Castro), but people, upon hearing the name,
are usually horrified to think that I've named my server for the Cuban
leader.  That name has ended up in many, many message IDs over the
years, and I know of still other much less savoury hostnames people have
used which will also necessarily appear in message IDs.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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

[PATCH 3/3] t4150-am: add a test for message-id header collection

[James Bottomley]

Since git am now always adds the message-id header, fix test 'am
applies patch e-mail not in a mbox' not to add the header because
otherwise the commit won't be equivalent to second and add a new test
that the message-id header gets correctly added.

Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
---
 t/t4150-am.sh | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 699a81ab5c..82603b2bbf 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -109,6 +109,12 @@ test_expect_success setup '
 		echo "X-Fake-Field: Line Three" &&
 		git format-patch --stdout first | sed -e "1d"
 	} > patch1.eml &&
+	{
+		echo "X-Fake-Field: Line One" &&
+		echo "X-Fake-Field: Line Two" &&
+		echo "X-Fake-Field: Line Three" &&
+		git format-patch --stdout first | sed -e "1d"
+	} > patch1-nomsgid.eml &&
 	{
 		echo "X-Fake-Field: Line One" &&
 		echo "X-Fake-Field: Line Two" &&
@@ -235,13 +241,25 @@ test_expect_success 'am applies patch e-mail not in a mbox' '
 	rm -fr .git/rebase-apply &&
 	git reset --hard &&
 	git checkout first &&
-	git am patch1.eml &&
+	git am patch1-nomsgid.eml &&
 	test_path_is_missing .git/rebase-apply &&
 	git diff --exit-code second &&
 	test "$(git rev-parse second)" = "$(git rev-parse HEAD)" &&
 	test "$(git rev-parse second^)" = "$(git rev-parse HEAD^)"
 '
 
+test_expect_success 'am adds message-id to the header' '
+	rm -fr .git/rebase-apply &&
+	git reset --hard &&
+	git checkout first &&
+	git am patch1.eml &&
+	test_path_is_missing .git/rebase-apply &&
+	git diff --exit-code second &&
+	test "$(git rev-parse second)" != "$(git rev-parse HEAD)" &&
+	test "$(git rev-parse second^)" = "$(git rev-parse HEAD^)" &&
+	git show --pretty=raw HEAD | grep "^message-id <1226501681-24923-1-git-send-email-bda@mnsspb.ru>"
+'
+
 test_expect_success 'am applies patch e-mail not in a mbox with CRLF' '
 	rm -fr .git/rebase-apply &&
 	git reset --hard &&
-- 
2.51.0

Re: [PATCH 0/3] add a message-id header to git

[Kristoffer Haugsbakk]

On Thu, Oct 16, 2025, at 20:57, James Bottomley wrote:
> There has been some debate in the kernel community about how to link
> commits back to email, which is the basis of a lot of scripting we do
>
> https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/
>
> However, this problem is one that goes beyond the kernel, so having
> git always track the message-id of the email used to create the commit
> will be useful beyond our tools as well.  The design of this
> message-id header is that it never shows up except in --pretty=raw
> output, so it will never be ordinarily visible, but can be extracted
> by scripts.  Some projects use the -m flag of git-am to add the
> Message-Id to the trailers and for backwards compatibility, this
> functionality is not changed although it is hoped that it is now
> redundant.

Related discussions: “Change-ID”:

https://lore.kernel.org/git/aOQWWkj%2Fq7GfKZY7@nand.local/

https://lore.kernel.org/git/20250703074952.20737-1-drew@ddevault.org/

https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf1Aa5gPr0FXzdcywqUUw@mail.gmail.com/

Inspired by Gerrit, Git Butler, Jujutsu, according to the last link.

Re: [PATCH 0/3] add a message-id header to git

[James Bottomley]

On Thu, 2025-10-16 at 21:26 +0200, Kristoffer Haugsbakk wrote:
> On Thu, Oct 16, 2025, at 20:57, James Bottomley wrote:
> > There has been some debate in the kernel community about how to
> > link
> > commits back to email, which is the basis of a lot of scripting we
> > do
> > 
> > https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/
> > 
> > However, this problem is one that goes beyond the kernel, so having
> > git always track the message-id of the email used to create the
> > commit
> > will be useful beyond our tools as well.  The design of this
> > message-id header is that it never shows up except in --pretty=raw
> > output, so it will never be ordinarily visible, but can be
> > extracted
> > by scripts.  Some projects use the -m flag of git-am to add the
> > Message-Id to the trailers and for backwards compatibility, this
> > functionality is not changed although it is hoped that it is now
> > redundant.
> 
> Related discussions: “Change-ID”:
> 
> https://lore.kernel.org/git/aOQWWkj%2Fq7GfKZY7@nand.local/
> 
> https://lore.kernel.org/git/20250703074952.20737-1-drew@ddevault.org/
> 
> https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf1Aa5gPr0FXzdcywqUUw@mail.gmail.com/
> 
> Inspired by Gerrit, Git Butler, Jujutsu, according to the last link.

So this is a different beast from change-id.  Change-id is used to
track the same change across different commits in a fully git based
workflow ... and in that workflow a message-id wouldn't exist because
there's really no email based interaction.  The reason email projects
need the message-id is so that all of the ci type tooling we have can
link a commit back to the email it came from (so tip bots use it to
reply when the commit is accepted and things).  In an email based
workflow there's not really such a thing as a global change-id and so
the two proposals are pretty orthogonal.

Regards,

James

Re: [PATCH 0/3] add a message-id header to git

[Kristoffer Haugsbakk]

On Thu, Oct 16, 2025, at 22:10, James Bottomley wrote:
> On Thu, 2025-10-16 at 21:26 +0200, Kristoffer Haugsbakk wrote:
>> On Thu, Oct 16, 2025, at 20:57, James Bottomley wrote:
>> > There has been some debate in the kernel community about how to
>> > link
>> > commits back to email, which is the basis of a lot of scripting we
>> > do
>> >
>> > https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/
>> >[snip]
>>
>> Related discussions: “Change-ID”:
>>
>>[snip]
>
> So this is a different beast from change-id.  Change-id is used to
> track the same change across different commits in a fully git based
> workflow ... and in that workflow a message-id wouldn't exist because
> there's really no email based interaction.  The reason email projects
> need the message-id is so that all of the ci type tooling we have can
> link a commit back to the email it came from (so tip bots use it to
> reply when the commit is accepted and things).  In an email based
> workflow there's not really such a thing as a global change-id and so
> the two proposals are pretty orthogonal.

They are not related in the sense that they mean the same thing.  They
are related in the sense that parts of the discussion is about using a
commit header to implement the idea.

Thanks

Re: [PATCH 0/3] add a message-id header to git

[Junio C Hamano]

James Bottomley <James.Bottomley@HansenPartnership.com> writes:

> There has been some debate in the kernel community about how to link
> commits back to email, which is the basis of a lot of scripting we do
>
> https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/
>
> However, this problem is one that goes beyond the kernel, so having
> git always track the message-id of the email used to create the commit
> will be useful beyond our tools as well.  The design of this
> message-id header is that it never shows up except in --pretty=raw
> output, so it will never be ordinarily visible, but can be extracted
> by scripts.  Some projects use the -m flag of git-am to add the
> Message-Id to the trailers and for backwards compatibility, this
> functionality is not changed although it is hoped that it is now
> redundant.

I am perfectly fine with mailinfo changes and it is OK to add it to
commit trailer, but to the commit object header?  Having to maintain
an extra header is a headache, in that you have to worry about what
rebases and cherry-picks would do to them.  Please don't.

I haven't carefully read [2/3] yet, but do we now forbid to run the
poor-man's rebase "git format-patch ... | git am" pipeline by
insisting that state->msg_id to exist in parse_mail()?  The output
of format-patch over existing commits may not have the message-id
headers.

Re: [PATCH 0/3] add a message-id header to git

[James Bottomley]

On Thu, 2025-10-16 at 13:32 -0700, Junio C Hamano wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> 
> > There has been some debate in the kernel community about how to
> > link commits back to email, which is the basis of a lot of
> > scripting we do
> > 
> > https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/
> > 
> > However, this problem is one that goes beyond the kernel, so having
> > git always track the message-id of the email used to create the
> > commit will be useful beyond our tools as well.  The design of this
> > message-id header is that it never shows up except in --pretty=raw
> > output, so it will never be ordinarily visible, but can be
> > extracted by scripts.  Some projects use the -m flag of git-am to
> > add the Message-Id to the trailers and for backwards compatibility,
> > this functionality is not changed although it is hoped that it is
> > now redundant.
> 
> I am perfectly fine with mailinfo changes and it is OK to add it to
> commit trailer, but to the commit object header?  Having to maintain
> an extra header is a headache, in that you have to worry about what
> rebases and cherry-picks would do to them.  Please don't.

My assumption was that any extra headers in the git object get carried
over, but if I need to do something to make that happen, then I can
certainly craft patches.

The reason for doing it as a header is just for it to be always there
for email workflow.  The trailer doesn't have the same property because
people forget to add it and Linus hates it and refuses to allow it in
kernel code.  I'm hoping the ubiquity will make up for the pain of
adding another header.

> I haven't carefully read [2/3] yet, but do we now forbid to run the
> poor-man's rebase "git format-patch ... | git am" pipeline by
> insisting that state->msg_id to exist in parse_mail()?  The output
> of format-patch over existing commits may not have the message-id
> headers.

So this one's a bit more deliberate.  If you import email and then re-
send as email we can't keep the same message-id; the internet RFCs
require us to keep message-ids unique, so git-format-patch won't output
the message-id.  That necessarily also means that the poor man's rebase
you cite above will still run, but it would drop the message-id header.

Regards,

James

Re: [PATCH 0/3] add a message-id header to git

[Junio C Hamano]

James Bottomley <James.Bottomley@HansenPartnership.com> writes:

> So this one's a bit more deliberate.  If you import email and then re-
> send as email we can't keep the same message-id; the internet RFCs
> require us to keep message-ids unique, so git-format-patch won't output
> the message-id.  That necessarily also means that the poor man's rebase
> you cite above will still run, but it would drop the message-id header.

That is one more reason why I do not want it in the header, or "-m"
to overwrite existing message-id trailer.  If I received a patch via
a message, applied, and forwarded it out of a commit I previously
created from a message I earlier received from elsewhere, I would
want the recipient of my forwarded patch message to be able to link
the message I forward with the original message, probably in the
mailing list archive where I took the message from in the first
place.

Re: [PATCH 0/3] add a message-id header to git

[Kristoffer Haugsbakk]

On Thu, Oct 16, 2025, at 23:18, Junio C Hamano wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> writes:
>
>> So this one's a bit more deliberate.  If you import email and then re-
>> send as email we can't keep the same message-id; the internet RFCs
>> require us to keep message-ids unique, so git-format-patch won't output
>> the message-id.  That necessarily also means that the poor man's rebase
>> you cite above will still run, but it would drop the message-id header.
>
> That is one more reason why I do not want it in the header, or "-m"
> to overwrite existing message-id trailer.  If I received a patch via
> a message, applied, and forwarded it out of a commit I previously
> created from a message I earlier received from elsewhere, I would
> want the recipient of my forwarded patch message to be able to link
> the message I forward with the original message, probably in the
> mailing list archive where I took the message from in the first
> place.

X-Git-Original-Message-ID:  ?

-- 
Kristoffer Haugsbakk

Re: [PATCH 0/3] add a message-id header to git

[Kristoffer Haugsbakk]

On Thu, Oct 16, 2025, at 20:57, James Bottomley wrote:
> There has been some debate in the kernel community about how to link
> commits back to email, which is the basis of a lot of scripting we do
>
> https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/

In that email:

JB> There has been a lot of discussion on the tooling list about how the
JB> loss of link trailers has updated both tooling and triaging issues.

I know of a recent[1] negative opinion about `Link`:

LT> It's not that it isn't "useful to me". It's that it HURTS, and it's
LT> entirely redundant.
LT>
LT> It literally wastes my time. Yes, I have the option to ignore them,
LT> but then I ignore potentially *good* links.

But has there been a decision that they are going away?  Do you have a
link to that discussion?  Just curious to know more. :)

[1]: https://lore.kernel.org/all/CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com/

You might know that the Git project tracks Message-ID for all commits in
`refs/notes/amlog`.  This is straightforward when only the maintainer
applies emails.  And up until three hours ago I thought it couldn’t work
beyond on person.

But maybe it could?

1. Everyone who wants to makes or shares a hook to add the Message-ID
2. (and maybe try to upstream a built-in way; this would be simpler to
   upstream than a new commit header)
3. Push out the notes ref along with all the other refs
4. The tooling (programs) fetch and merge all of them (from the repos
   they know about)
5. With only a collection of remotes that run a hook to add a line to
   each incoming commit: the tools can merge all repos since people will
   not apply a patch and get a hash collision with someone somewhere
   else
6. (“the tools” here since you seem to focus on CI or general tooling)
7. Consumers can fetch this note and have all known mappings

Would this work among nice, cooperating individuals?  (That don’t try to
confuse the tooling by notes for commits that already exist in other
repos.  For some reason.)

A more careful/structured implementation could also check that the
incoming notes are all (1) only additions, (2) one-line notes, (3) only
annotate commits that the notes-committer has committed (note committer
and commit committer are the same...).  But I guess for (3) to be
meaningful you have to manually map repositories to committers.
E.g. repository for Bob may only annotate commits by himself.  Or you
can sign the note commits if that is necessary.

Related sub-discussion on the linked thread:

https://lore.kernel.org/ksummit/68ee73dcd10ee_2f89910075@dwillia2-mobl4.notmuch/

On the one hand, pushing and fetching notes does not necessarily sound
like it would fit in an email workflow (*too* integrated with git(1)?).
But your reply here does not mention that kind of objection so I will
soldier on:

https://lore.kernel.org/ksummit/146639e2bc8b5327f57e4297f5a0fcfd3c86d95c.camel@HansenPartnership.com/

JB> I think part of the problem with notes is they're designed not to be
JB> shared.

They aren’t designed to not to be shared, but you are getting at a real
usability downside for individuals. They are “designed” to be hard to
consume/fetch in setups where every single user needs to set up a
refspec in order to fetch them for them to be useful.

But you seem to focus on tooling.  For tooling they shouldn’t be any
harder to set up than anything else.

So yeah the downside is for individuals who just want to be able to
opt-in to pretty-print the Message-IDs; they would have to set up a
refspec to get the Message-IDs, just like they do here in Git.

They don’t get it for free from the Git commit object itself.

JB> So there are lots of diverse internal uses for notes that
JB> aren't just the annotations you're thinking of here, so when I push to
JB> a notes tree, I'd likely have to filter and when I pull from it I
JB> wouldn't necessarily want everyone else's notes ... it's like when you
JB> forget to add --no-tags to a pull from someone else's tree and you get
JB> a load of their internal tags that contaminates your internal tag pool.

You get all the blobs for the notes.  They take up disk space but they
don’t pollute things beyond that.

JB> Yes, but not all subsystems would care about everything even in this
JB> notes driven annotations model ... so you either have to have filter on
JB> pull or strict rules about what goes in, which then causes issues with
JB> local notes uses.

With one blessed notes namespace for Message-IDs, where’s the potential
conflict?  Those who care can fetch.

See previous paragraphs about merging notes across repositories.

With all that naively said: note objections by Konstantin Ryabitsev.

https://lore.kernel.org/ksummit/20251015-versed-active-silkworm-bb87bd@lemur/

>
> However, this problem is one that goes beyond the kernel, so having

Are there examples of projects where this is a pressing need?  I would
imagine it is not for smaller email-based projects.

I’m asking because it is good to be specific in the cover letter for a
major change.  More than just stating that other cases exist.

>[snip]

Re: [PATCH 0/3] add a message-id header to git

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> But has there been a decision that they are going away?  Do you have a
> link to that discussion?  Just curious to know more. :)
>
> [1]: https://lore.kernel.org/all/CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com/

I think the latest is:

https://lore.kernel.org/all/CAHk-=wj5MATvT-FR8qNpXuuBGiJdjY1kRfhtzuyBSpTKR+=Vtw@mail.gmail.com/

regarding the "Link:" thing.