Linus Torvalds Expresses Frustration With 'Garbage' Link Tags In Git Commits (phoronix.com) 82
"I have not pulled this, I'm annoyed by having to even look at this, and if you actually expect me to pull this I want a real explanation and not a useless link," Linus Torvalds posted Friday on the Linux kernel mailing list.
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 longer discussion ensued...
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 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.
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:Documentation is a tech skill (Score:5, Informative)
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 and further muddying the waters by forcing someone to read through both the code, the documentation, and the test, to determine that there's no additional value to the documentation or the test over the code.
I guess this would be the point in time to discuss how aggressive to be in terms of adopting forced syntax reformatting, pre-commit and commit linters, and tests? And god forbid, checklists for each commit?
Re: Documentation is a tech skill (Score:2)
Documentation is different from syntax checkers, tests and linters. While there may be a valid reason for any of those to miss or fail, I can't thibk of such a reason for documentation. Even if it's just "nothing to see here, move along" -- that in itself is already important enough to be documented.
Re: (Score:2)
Even if it's just "nothing to see here, move along" -- that in itself is already important enough to be documented.
Exactly. "This is boilerplate, no surprises" is a quite valuable comment and it needs to be there. Really reading code is generally more effort than writing it. Comments reduce that effort and can, if very good, mostly eliminate it. Sure, for write-once code that never gets maintained, comments become just additional effort, bit such code has no or negative value in the first place.
unconcerned (Score:5, Interesting)
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 code, untested, of unknown quality in most applications today
- How WebAPI and its precursors shifted calling, error checking, parameter checking and connection protocol handling from the software being called to the developer making the call
- How vendor API documentation mostly excludes any information or sample code on handling errors, allowing tens of thousands of cut and paste re-use instances of that code to live in critical production systems today
- How variant became the most popular datatype through the proliferation of JavaScript, Typescript and Python (Any) when older languages like VB6 discouraged the use of Variant data types
How YAGNI fell into disuse because best practices require systems have structure A, B, C and D regardless of need
Re:unconcerned (Score:5, Insightful)
OMG THIS!!! A million times this!!! You have hit on every pet peeve of mine that has become a norm with the advent of the "everyone can code" movement. What used to be an elegant art form of writing bullet proof software to withstand the test of time has devolved into a "we'll clean it up later" enshitification of the craft. I used to see mind-blowing artisans at work, then came the StackOverflow cut-and-pasters, then the "duct tape 20 packages together" to print a string to stdout, and now the vibe coders with 3000-line PRs of AI slop.
Every sign points to a new COBOL-esque super cycle where graybeards get pulled in to scape away countless layers of machine-generated "code" in order to get a broken system back on track.
Re: (Score:2)
Well, maybe. Some industry giants (MS...) are certainly headed for a cliff. And LLMs mostly seem to help attackers, not defenders, making things so much worse.
As to "graybeards getting pulled in" to clean up all the collapsing infrastructure, maybe. I am sure if I get asked I will charge them an arm and a leg though.
Re: (Score:2)
where graybeards get pulled in to scape away countless layers of machine-generated "code" in order to get a broken system back on track.
Anyone remember 4GLs? "Forth Generation Languages" which had some popularity in the 1990s, where you write code in a higher level language which then gets compiled to something like C, which can subsequently be compiled in the normal manner.
It's all good until the proprietary 4GL vendor goes out of business, and (after grumbling about the original choice of proprietary software) you are left with the machine-generated C code to maintain. About as much fun as a visit to the dentist in the 19th century.
Re: (Score:2)
Does anyone, anywhere these days know the pleasure of writing 10-20 lines of code, leaning back and saying to themselves, "that's beautiful".
Re: (Score:3)
While I am not happy about the modern norms as well, this
has not been true anymore even before I was born and I am close to 50.
Re: (Score:2)
I do not think this is a new thing. Developers so in awe with what they can to that they never stop to think what they can break or how awful a mess they can make or whether security is a concern and how to address it, probably has been an ongoing thing since computers became more generally available, i.e. for the last 40-50 years or so.
Re: (Score:2)
Re: (Score:2)
Python is actually a pretty good language in the hands of a competent (!) developer.
Agree (Score:2)
>Python is actually a pretty good language in the hands of a competent (!) developer.
Agree. Decent developers write decent code in most any language. Then again, it is possible to write "Fortran in any language" as the saying goes.
Somewhere, we may discover that beyond a certain number of lines of code, going from an any/variant dynamic object based language (javascript, python, typescript) to one with declared types checked at compile time is worth doing. The major languages, beyond Rust/Go have bee
Re: (Score:2)
Re:Documentation is a tech skill (Score:5, Funny)
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:Documentation is a tech skill (Score:5, Insightful)
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:Documentation is a tech skill (Score:4, Insightful)
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.
"Probably"? Heck, if it's not something I've worked on recently - until I look at the comments, I typically have very little idea what my thought processes were (regarding particular code) even just 6-12 months ago.
It might be easier for people with a more narrowly-defined job... but like most people who are part of a small IT team, I end up wearing a lot of hats.
Tangent: Hopefully I'm not to the only one who looks at his own code from a few years before and sometimes reacts "what the heck was I thinking?"... not because I don't understand what the code is doing, but because I don't understand *why* I chose to do it that way.
Re: (Score:1)
I might be a special case, ha ha, but I sometimes don't remember doing it at all, let alone why I did it. But there is my signed comment showing me that I did. More and more often I provide a link which actually does wind up explaining.
Re: (Score:2)
Happens to me as well, if not very often these days.
Re: (Score:2)
Fucks sake what moron wrote this shit...
git blame
I mean what developer. Clearly a genius, handsome and so modest.
Re:Documentation is a tech skill (Score:5, Funny)
Re: (Score:3)
That was me after a few months early in my career.
At the same time one of the cofounder write all his Perl code with 2 letter function names and 1 letter variables. I tried to have him improve this, but I was a lowly intern and he was a cofounder. His argument was that he needed to type code as fast as he could think and that his code was always feature complete and bug free on the first write so readable code was useless... I was the one adding features and fixing bugs, so of course he personally had no ne
Re: (Score:2)
His documentation was perfect according to him, it had gems such as "open server.xml and make sure it is correct"
It's not clear what is wrong with this.
Re: (Score:2)
There was no explanation of what "correct" was. We had 3 production servers and all config files were different, they were supposed to be consistent.
I had him sit down with me to review the settings then wrote code to automatically write the "correct" files.
Re: (Score:2)
His argument was that he needed to type code as fast as he could think...
It must have been tough for him to be that slow of a typist.
Re: (Score:2)
Nah, smart guy and fast typist. I see him as a prototyper which thrives to get things done in a snap then move on to an other project. The kind that cuts and don't bother measuring once, then forces things to kinda fit together, but by then that's someone else issue. I'm more of a production ready type, it might take longer initially but I don't want to have to redo the work 3 times.
He is a fast talker as well, so fast that stenographers asked him to slow down.
Re: (Score:2)
You aren't a Real Software Engineer until you've looked at a piece of code, asked "What fucking idiot wrote this", and found out it was you.
I'm disappointed in the mods that tagged this "Funny", when it should be "Insightful". It is funny, of course, but it's more insightful than funny.
Oh... and by that metric I'm definitely a Real Software Engineer. I have done that dozens of times, at least.
Re: Documentation is a tech skill (Score:2)
Re: (Score:2)
Eh, I maxed out my karma years ago, so the upvotes are just for feelings anyway.
Hasn't everyone maxed their karma? I just mean that "Insightful" is more accurate than "Funny".
Re: (Score:3)
Comments are a love letter to your future self.
Re: (Score:2)
Exactly. This is why my blood pressure spikes whenever I see some damn kid (#GOML) squeaking that "comments are a code smell."
The original point has been lost, corrupted into cargo-cult stupidity.
Re: (Score:2)
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)
Yep, same here. And then I had students working with my code and telling me it was surprisingly readable and well documented. It really is a win-win.
Re: (Score:2)
You joke, but anybody that really has this attitude should be banned from professional coding for life.
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:1, Offtopic)
Re: (Score:2)
I disagree. And you might have noticed what he created but probably did not understand that. It is just the largest software project the human race ever has successfully made to work and it is on an advanced complexity level. So, no, he is decidedly not "bad at communicating".
Re: (Score:2)
Regarding largest successful software project, I d
Re: (Score:2)
You obviously have no tech skills. Otherwise you would understand that getting a project of this type to work is without precedent and it cannot be overstated how much of an achievement that is. And here you are, cluelessly nit-picking.
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)
No argument. With "these days" I mean that despite the now excessively high importance of software, the art still is in a really bad shape.
Re: (Score:2)
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:Documentation is a tech skill (Score:5, Informative)
“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! https://www.kernel.org/doc/htm... [kernel.org] 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: 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.
Re: (Score:2)
Re: (Score:2)
Perfect. Then why doesn’t the Linux review team take it a step further and just reply with “Please update submission commit message to satisfy rule 123 part whatever.”? Genuine question.;
The context I think you're missing (and very much excused for) is that Axboe is a kernel maintainer, part of the "review team" if you will (Ryabitsev is a linux foundation sysadmin and Mateos is the author of the patch).
Rather than expending the time and energy of many debating , and getting nowhere..”
(Re)read the thread and I'm quite sure it will become clear: https://lore.kernel.org/all/9e... [kernel.org]
Re: (Score:2)
Re: (Score:2)
Politeness is not what made the Linux kernel a reality and the most successful large-scale software project ever. Clarity of communication played an important role though.
Re: (Score:2)
And yet so many companies pay technical writers very poorly and often don't ever bother even consulting one. Documentation is often just an afterthought, inadequate, inaccurate and created by people who can't communicate even within the team they work with. Don't get me started on management either. Most companies just don't care, it's all about maximizing profits, minimizing quality and proper documentation would just provide a clear view of their incompetency, so they happily fail to budget for it. There'
Re: (Score:2)
No argument. Bad management is to blame for a lot of bad tech (including documentation).
Who is this for? (Score:2)
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)
Re:Who is this for? (Score:4, Insightful)
What Linus is complaining about is a git patch that has a link to the same patch in LKML. But, presumably, in the future that will be useful to people looking back and seeing that link who will be able to see not only that patch but the entire following discussion on it. Linus is looking at it with a "what does this buy me today", which is admittedly nothing. But this buys other people information tomorrow, which is how foresighted people are looking at it as they include the link.
Re: (Score:2)
^ this exactly was my reaction as well and why i'm not with him on it. cross-linking between the the MR, the jira , the slack threads etc. whether manual or automatic is very useful to people trying to find context.
That said i do think that links should have a description of what the link takes you to so that you know if it's worth looking there. i.e. things like "original motivation" or "more comments on evolution of the data structure" or whatever.
He's coming off EXTREMELY self-centered here as if
Re: (Score:2)
.. as if only process matters.
"as if only HIS process matters", i meant.
Re: (Score:2)
What he's complaining about is the ones that are linking to the final version of the patch, after problem reports, patch discussions and ACKs and such were all in other threads - those threads are typically just "here's the final patch". There's no discussion to be read there. Typically there's a whole lot more that happened before, but that's not what's getting linked in some of these patches.
The intent of the Link: is to link to the problem report, debugging, discussion of the problem/patch... and some do
Re: (Score:2)
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 https://lkml.org/lkml/2025/9/7... [lkml.org]"
(Please note that I just picked a mailing list message at random)
Re: (Score:2)
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.
This is the perfect time... (Score:4, Funny)
...to approach the good people at Microsoft to continue this project under their caring and steady stewardship for when that fell time comes.
Re: (Score:2)
ok he's good but someone BETTER would not have a mental breakdown, just write a note "use the 'link' only to point at additional information beyond what is already on the LKML" and that would be it.
Re: (Score:2)
ok he's good but someone BETTER would not have a mental breakdown
Are you sure about that? The amount of stress that likely goes with the chief maintainer is likely very, very high.
Also, consider this: irritation like this serves a real purpose. It keeps contributors on their toes and pushes them to have higher quality submissions. Some level of fear of criticism is useful (a balanced level of fear - clearly too much and nobody would contribute). The amount of crap that still gets through is likely still high and the sheer volume would likely drive the "better" person to
Year of Linux on the Desktop (Score:2)
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 zodiac [wikipedia.org] if they had included the "Year of the Penguin" so we'd have a better idea when to expect this. :-)
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)
Re: (Score:3)
Heh. i'm in the middle. I appreciate him for maintaining standards when it's so easy to just let things go so as not to make waves.
OTOH fully agree on the communication style and personal blame aspect. It's usually not too hard to refocus the phrasing on the activity and to express a preference for something without flipping your lid.
Re: (Score:1)
how is this "flipping your lid" - he explained his position, with words and logic. he did not beat anyone up, delete the program, fire the person, or anything else like that.
are people so soft now that they cannot be told they are wrong and this is why and this is how to do it better?
Re: (Score:2)
But he's also changed.
He's replaced performative invective with very firm but rationally expressed opinions. That's much better IMO.
Re: (Score:2)
If you're going to paste a link, it NEEDS to add something of value.
This is valid... but you also have to consider that the value may be to someone other than Torvalds. It may be to people in the future who look at git blame looking to understand why something is the way it is, and for them a link to the patch email and any discussion that followed it may be very useful.
Perhaps they need to define a new tag "TorvaldsLink:", or less snarkily, "ReviewerLink:", that indicates that the link's intention is to provide information for the reviewer, so Torvalds knows that it's m
Thank goodness for ethical responsible leadership! (Score:2)
Linus for president.
Thank you, Linus! (Score:1)
Thank you, Linus. Your grumpiness and skepticism in confronting unclear pull requests is much appreciated by every Linux user, it shows how much you actually care. Never change!
Link to original post makes sense (Score:2)
Those of us in the corporate world that have decades of experience in doing useless busywork are somewhat partial to adding a useless link to the patch submission. Even though anyone could look it up from the title in the Git commit. Also, nobody cares to see the LKML thread. But dammit doesn't feel nice to do additional paperwork?
this _has_ been going on for years (Score:2)
Maybe one should communicate such things when they first annoy one and not wait to become frustrated.
A better commit message (Score:2)
"Various bugfixes and enhancements."
It's good enough for proprietary software, why not Linux too?