Linus Torvalds has a blunt message for Linux kernel contributors: stop stuffing commit messages with “Link:” trailers that add zero context. The kernel’s creator recently pushed back on a proposed change that included a reference pointing back to the same information already in the patch discussion. His frustration is not about etiquette; it’s about time. When a link fails to provide new data—like a crash log, discussion thread, or bug tracker entry—it forces maintainers to chase dead ends, and that slows the entire project.
Why “Link:” tags are under fire
Kernel patches often include a “Link:” trailer intended to cite the origin of the issue or the broader discussion. Torvalds’ complaint is specific: links that loop back to the same email, a generic project page, or a duplicate explanation waste attention without improving traceability. In the case he flagged, he expected a pointer to an error report or a conversation that justified the change. Instead, the link offered nothing he hadn’t already read, which made the patch look superficial and, worse, untrustworthy.
Linux’s own documentation on submitting patches encourages references that expand context—bug reports, mailing-list threads, and test artifacts—not filler. A “Link:” is there to capture provenance and rationale, not to satisfy a template.
Automation and AI are part of the problem
Modern tooling makes it easy to add noise. Repository platforms routinely auto-insert cross-references between issues, merge requests, and emails. Developers increasingly lean on AI assistants to draft commit messages. The result: a surge of mechanically generated “Link:” lines that don’t deepen understanding. As AI usage grows across software teams—something echoed in recurring developer surveys—so does the risk of bland, low-signal summaries masquerading as documentation.
Torvalds’ stance is not anti-automation. It is pro-signal. If a bot or assistant can attach a kernel oops trace, a syzbot report, or a bisect result that explains the failure, great. But a link that merely points back to the patch email or to a landing page without diagnostic detail is worse than useless; it costs maintainers cognitive overhead with no payoff.
What a useful link actually looks like
There are clear examples of high-value links in kernel workflows. A reference to a mailing-list thread that captures a prior NAK and the revised approach helps reviewers understand what changed and why. A link to a kernel bug tracker entry with reproduction steps and affected hardware grounds the patch in observable behavior. A syzkaller or syzbot ID that includes the crash signature, kernel version, and public triage history is gold. Even a reference to a vendor advisory with root-cause notes can be relevant when it explains a real-world failure mode.
On the other hand, don’t link to a generic project page, your fork’s top-level repository, or the same email thread without additional content. If the link doesn’t offer new facts—logs, traces, benchmarks, perf regressions, design discussions—leave it out and strengthen the commit message instead.
Maintainer time is scarce—and measurable
The Linux kernel is a massive, fast-moving codebase with more than 40 million lines and thousands of changes each release cycle. Public analyses from the Linux Foundation and long-running community reports show that every merge window brings on the order of ten to fifteen thousand non-merge commits from hundreds of contributors. Every minute a maintainer spends clicking through redundant links is multiplied across subsystems and reviewers, turning small inefficiencies into a real tax on velocity.
It also erodes trust. A patch that punts its justification to a hollow link reads like it was churned out by a script. Maintainers aren’t grading style; they’re evaluating whether code is safe to merge. Clear, direct reasoning beats placeholder references every time.
How to meet the bar Torvalds is setting
Start with a crisp explanation in the commit message: what broke, how it was observed, why this change fixes it, and what risks remain. If you include a “Link:”, make sure it adds something the message doesn’t—an oops log, a kernelci report, a prior discussion thread, a reproducible test, or a bisect transcript. Prefer traceable artifacts like syzbot reports over ambiguous references.
Use trailers that maintainers rely on: “Fixes:” for the commit that introduced the bug, “Reported-by:” for the reporter, “Tested-by:” to document validation, and only then “Link:” for supplemental context. Run standard checks, get at least one subsystem review, and prune any auto-generated fluff before sending to the mailing list.
AI is no excuse for low-quality patches
Assisted tools can accelerate development, but they don’t absolve authors from responsibility. If an AI or a platform integration inserts a link that doesn’t help a reviewer understand the bug, remove it. Torvalds’ message is straightforward: don’t outsource judgment. In the kernel, clarity is a feature, and noise is a bug.