Linus Torvalds has issued an unfriendly reminder to kernel contributors: if your pull requests aren’t generated by git tools built into the kernel, you’re doing it wrong, and he will not be hampered so that to accommodate your bad workflow.
These boilerplate references are a waste of maintainers’ time and simply get in the way of the signal that maintainers need to make fast, correct decisions, the keeper of the Linux kernel wrote in a blunt note on the Linux Kernel Mailing List.
The gripe: redundant links, no value
The stumbling block was an ordinary fix that contained one small additional code — a “Link:” entry that teased context. It just spun around to the same patch description it was already looking at. Torvalds had a simple message: include the link only if it provides new context that isn’t in the commit message—crash logs, regression reports, benchmarks, or earlier discussion that influences the decision. Anything else is noise.
This is not a pedantic nitpick. “tags To: and Cc:, known as `metadata tags` (Link:, Fixes:, Reported-by: etc) are used by kernel maintainers to quickly triage patches. Then a “Link:” that links to a copied summary, a bot-created page, or back to the email thread but without further information sends the reviewer out to dig for it, or to just give up and lose context.
How it got worse with automation
Tooling is part of what contributes to the mess. Non-human learners, such as CI bots, integrations on repos and helper scripts will often auto-insert link lines while submitting. They can be helpful when they link a patch to some upstream bug tracker or an earlier mail with significant technical reasons. But many just direct us back to the patch itself or a generic landing page where we did not find any new content.
And now there’s the growth of AI-helped workstreams. Some editors use templates or automatic summaries that create “Link:” fields automatically. As they rush through, fields escape them only to leave behind a shell of comprehensiveness, not the substance reviewers are after.
Why it matters for kernel speed
Each merge window brings its share of changes—usually in the form of ten or fifteen thousand non-merge commits according to counts that are occasionally quoted by maintainers and generated by various community analyses. BTW, LKML itself receives a flood of mail each day. Small inefficiencies start to compound at that scale. Scaling to circle through such links for each patch can waste seconds per patch and hundreds of hours of review capacity across the maintainer network.
The kernel project succeeds (in part) thanks to fast, confident decisions of subsystem maintainers and from Torvalds during pulls. When the commit messages are clear, and the “Link:” fields actually add to the story, link (on a regression tracker entry, a long-form bug report, performance data) the reviewer has all the context to either accept, put off, reject with little back and forth.
What a legitimate “Link:” looks like
herehereKernel documentation on submitting patches suggests commit messages that can stand on their own but provide urls for the curious to be led on. High-value examples include:
• A link (or a summary) of a bug tracker entry that includes reproduction steps and affected version.
• Ask for a reference to the previous LKML discussion that was used to compare competing approaches.
• A reference to the regression reports kept by the community’s regression tracker detailing when an issue first appeared.
• A reference to some performance or correctness data (e.g., CI results from something like KernelCI) and pasting this in-line would make for a bulky commit message.
In either case, the link needs to provide something that the above summary does not already mention as being in the patch. If the commit message completely details the problem being addressed and the solution, then you don’t need “Link:” and you shouldn’t feel guilty about it.
Keep the human in the loop
Automation is meant to aid, not supplant, editorial judgment. Contributors should scan through the auto-generated tags and delete anything that does not do enough work to justify its presence before hitting send. Maintainers recommend committing messages are short, self-contained with basic context and then selectively adding a couple of references for deep dives.
That’s twice as true for rookies who stick to templates like gospel. The kernel community likes conventions, but it likes clarity better. A concise commit with a good reason will always win over a verbose commit with useless references.
A broader push for signal over noise
For a long time, Torvalds has been pushing for pragmatic communication: clear subject lines, exact explanations and metadata that helps reviewers do their work. Here, too, his latest warning fits that pattern. With a codebase of many tens of millions of lines, and contributions from thousands of developers, the Linux project relies on habits that scale.
The lesson is simple: when a link does a better job of explaining something than the commit message—use it. If it’s just echoing what’s already there — get rid of it. That little bit of curation respects maintainers’ time and keeps the world’s most important open-source project moving fast and securely.
