Linus Torvalds Expresses Frustration With 'Garbage' Link Tags In Git Commits (phoronix.com)
- Reference: 0179068774
- News link: https://linux.slashdot.org/story/25/09/07/177225/linus-torvalds-expresses-frustration-with-garbage-link-tags-in-git-commits
- Source link: https://www.phoronix.com/news/Linus-Torvalds-No-Link-Tags
[2]Phoronix explains :
> It's become a common occurrence seeing "Link: " tags within Git commits for the Linux kernel that point to the latest Linux kernel mailing list patches of the same patch... Linus Torvalds has had enough and will be more strict against accepting pull requests that have link tags of no value. He commented yesterday on a block pull request that he pulled and then backed out of:
>
> "And dammit, this commit has that promising 'Link:' argument that I hoped would explain why this pointless commit exists, but AS ALWAYS that link only wasted my time by pointing to the same damn information that was already there. I was hoping that it would point to some oops report or something that would explain why my initial reaction was wrong.
>
> "Stop this garbage already. Stop adding pointless Link arguments that waste people's time. Add the link if it has *ADDITIONAL* information....
>
> "Yes, I'm grumpy. I feel like my main job — really my only job — is to try to make sense of pull requests, and that's why I absolutely detest these things that are automatically added and only make my job harder."
A [3]longer discussion ensued ...
Torvalds: [A] "perfect" model might be to actually have some kind of automation of "unless there was actual discussion about it". But I feel such a model might be much too complicated, unless somebody *wants* to explore using AI because their job description says "Look for actual useful AI uses". In today's tech world, I assume such job descriptions do exist. Sigh...
Torvalds: I do think it makes sense for patch series that (a) are more than a small handful of patches and (b) have some real "story" to them (ie a cover letter that actually explains some higher-level issues)...
Torvalds also had two responses to a poster who'd said "IMHO it's better to have a Link and it _potentially_ being useful than not to have it and then need to search around for it."
Torvalds: No. Really. The issue is "potentially — but very likely not — useful" vs "I HIT THIS TEN+ TIMES EVERY SINGLE F%^& RELEASE".
There is just no comparison. I have literally *never* found the original submission email to be useful, and I'm tired of the "potentially useful" argument that has nothing to back it up with. It's literally magical thinking of "in some alternate universe, pigs can fly, and that link might be useful"
Torvalds: And just to clarify: the hurt is real. It's not just the disappointment. It's the wasted effort of following a link and having to then realize that there's nothing useful there. Those links *literally* double the effort for me when I try to be careful about patches...
The cost is real. The cost is something I've complained about before... Yes, it's literally free to you to add this cost. No, *YOU* don't see the cost, and you think it is helpful. It's not. It's the opposite of helpful. So I want commit messages to be relevant and explain what is going on, and I want them to NOT WASTE MY TIME.
And I also don't want to ignore links that are actually *useful* and give background information. Is that really too much to ask for?
Torvalds points out he's brought this up four times before — once in 2022.
Torvalds: I'm a bit frustrated, exactly because this _has_ been going on for years. It's not a new peeve.
And I don't think we have a good central place for that kind of "don't do this". Yes, there's the maintainer summit, but that's a pretty limited set of people. I guess I could mention it in my release notes, but I don't know who actually reads those either.. So I end up just complaining when I see it.
[1] https://lore.kernel.org/all/CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com/
[2] https://www.phoronix.com/news/Linus-Torvalds-No-Link-Tags
[3] https://lore.kernel.org/all/CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com/#r
Who is this for? (Score:2)
Are the link tags there for Linus, or are they there for others who may not have already read the docs/mailing list? If it is the latter then the question becomes are they useful for those people, not are they useful for Linus. I suspect this to be the case, and I'm not sure this story actually answers that question.
Re: (Score:3)
But a patch with a link to the patch is not a useful link. The link should point to the problem report or at least discussion. That's what Linus is complaining about - people are using Link: to link to the final version of the patch on LKML which at most has "Ack" replies. That adds zero useful information.
Re: (Score:2)
Fair enough. I don't read kernel sources myself so I guess the story was not clear enough for me.
Re:Who is this for? (Score:5, Informative)
So if I'm understanding the context correctly... the problem is the commit messages don't actually explain what the change does, it just gives a URL to the mailing list discussion regarding the bug. e.g. the full commit message is
"https://lkml.org/lkml/2025/9/7/262"
versus
"Update call sites in `task.rs` to import `ARef` and `AlwaysRefCounted` from `sync::aref` instead of `types`. Additional info at [1]https://lkml.org/lkml/2025/9/7... [lkml.org]"
(Please note that I just picked a mailing list message at random)
[1] https://lkml.org/lkml/2025/9/7/262
Re: (Score:2)
OK, that makes a lot more sense, thanks.
And what happens then? (Score:3)
It seems like when the inevitable happens and Linus can no longer do this job, the coding practices he enforced no longer will be. He is in that position because it was his to begin with, but who gets to be the gatekeeper after that?
I have a hard time imagining it will be someone (and certainly not a committee) who will be as good as he has trained himself to be.
Year of Linux on the Desktop (Score:2)
Sounds like everything is on track for the year 2053 being Year of Linux on the Desktop.
Re: (Score:3)
> Sounds like everything is on track for the year 2053 being Year of Linux on the Desktop.
Ya know... The Chinese could have done everyone a favor when they came up with their [1]zodiac [wikipedia.org] if they had included the "Year of the Penguin" so we'd have a better idea when to expect this. :-)
[1] https://en.wikipedia.org/wiki/Chinese_zodiac
used to dislike Torvalds... but the older I get, (Score:3)
used to dislike Torvalds... but the older I get, the more his ways/views aligns with mine. He simply has no tolerance for people wasting time with stupidity and has been true to that with his work. If you're going to paste a link, it NEEDS to add something of value. If it simply circle jerks itself with not added context/new information, then they can fuck off. It's akin to msft and their updates and looking them up... often, the links circle back into each other not clarifying what it actually is... You'll end up running in circles trying to figure out what they're actually for.
Re: (Score:2)
I'm in agreement with everything you said... except that, in this case, I expect the issue isn't stupidity - it's simply laziness.
Which is actually worse.
Re: used to dislike Torvalds... but the older I ge (Score:2)
For me, it is the opposite. The older I get, the less I get annoyed by other people's mistakes. It's also a question of communication style when pointing fingers. The way Torvalds complains about such things, at his age, makes him look like a weak person.
Documentation is a tech skill (Score:5, Insightful)
Seems quite a few people are overlooking that little detail these days. Either document well or stay out of important tech projects, FOSS or otherwise.
Re: (Score:2)
While I understand that sometimes it's a communication skill, or a habit thing, I wonder if sometimes the lack of an explanation is itself a red flag that whoever opened the PR or made the commit lacks understanding of what they were supposed to do, and what they actually did...
On the other hand, ticking off a checkbox item so that the linter passes by putting in useless information is the same as a garbage test written to make sure there's sufficient code coverage to make a linter pass. A waste of time an
unconcerned (Score:1)
Hasn't there been a slackening of concern since 2000?
- How ORMs for many developers mean that they don't design the database, check constraints, referential integrity rules, and other data quality measures?
- How languages allowing dynamic properties and methods to be added to in-memory objects at run-time allows developer to avoid designing classes, enforcing type checking, and letting the compiler do the first unit test?
- How the pyramid of packages allows developer to include tens of thousands of lines of
Re: (Score:2)
Or just skip the documentation. If it was hard to write, it should be hard to understand. :-) :-)
Re: (Score:2)
You have me both laughing and banging my head against the desk... the latter is because I've known people who seem to actually think like that.
Re: (Score:2)
> You have me both laughing and banging my head against the desk... the latter is because I've known people who seem to actually think like that.
And documentation isn't just for others. Wait long enough and you'll probably need it for you own code -- I learned that (way, way back) early on with Perl and regular expressions. I always try to code, document (or do sysadmin) thinking, what if I get hit by a bus tomorrow and someone else has to take over. Also, "If you don't have time to do it right the first time, when will you the second time?"
Re: (Score:2)
This is about git commit messages, not documentation. If your point is that some people are bad a communicating, you're proven it on the comprehension side.
Re: (Score:2)
Linus is bad at communicating. He should just get someone to document whatever his requirements are, and then non-compliant merge requests can just be politely flagged with a reference to that document. That’s how grownups do it in professional software development. Maybe these free hobby enthusiast FOSS projects could try it too.
Re: (Score:2)
> Seems quite a few people are overlooking that little detail these days.
"These days" being the past 25 years at a minimum, in my experience anyway. It's a huge problem with both code and processes in general.
Employing the gentle arts of mockery and derision, a former co-worker taught me the importance of consistently documenting my work. He drove me nuts at times, but thanks to him I think I've become a decent documenter. Since he left, I've taken on the mantle of chief-brow-beater-in-residence.
Re: (Score:2)
“Document well” goes for the submission guidelines and version control workflow too. For example:
> Torvalds: No. Really. The issue is "potentially — but very likely not — useful" vs "I HIT THIS TEN+ TIMES EVERY SINGLE F%^& RELEASE". Torvalds points out he's brought this up four times before — once in 2022. Torvalds: I'm a bit frustrated, exactly because this _has_ been going on for years. It's not a new peeve.
Isn’t there some kind of documentation of the contribution, commit and approval workflow guidelines, recommendations and requirements? Does Linus or anyone on the Linux project actually document all this tribal knowledge or do they just get their knickers in a twist “ten times every single release” because people aren’t reading their mind?
Re: (Score:2)
> “Document well” goes for the submission guidelines and version control workflow too.
> For example:
>> Torvalds: No. Really. The issue is "potentially — but very likely not — useful" vs "I HIT THIS TEN+ TIMES EVERY SINGLE F%^& RELEASE".
>> Torvalds points out he's brought this up four times before — once in 2022.
>> Torvalds: I'm a bit frustrated, exactly because this _has_ been going on for years. It's not a new peeve.
> Isn’t there some kind of documentation of the contribution, commit and approval workflow guidelines, recommendations and requirements?
> Does Linus or anyone on the Linux project actually document all this tribal knowledge or do they just get their knickers in a twist “ten times every single release” because people aren’t reading their mind?
Yep! [1]https://www.kernel.org/doc/htm... [kernel.org] [2]https://github.com/torvalds/li... [github.com]
> If related discussions or any other background information behind the change can be found on the web, add ‘Link:’ tags pointing to it. If the patch is a result of some earlier mailing list discussions or something documented on the web, point to it.
> When linking to mailing list archives, preferably use the lore.kernel.org message archiver service. To create the link URL, use the contents of the Message-ID header of the message without the surrounding angle brackets. For example:
> Link: [3]https://lore.kernel.org/30th.a... [kernel.org]
> Please check the link to make sure that it is actually working and points to the relevant message.
> However, try to make your explanation understandable without external resources. In addition to giving a URL to a mailing list archive or bug, summarize the relevant points of the discussion that led to the patch as submitted.
[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html
[2] https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst
[3] https://lore.kernel.org/30th.anniversary.repost@klaava.Helsinki.FI