Linus Torvalds has grown frustrated enough with seeing “Link: ” tags within Git commits/patches that often times they are of no value and he’s had enough of it. For Linux kernel activity moving forward he’s going to be more strict over “useless” link tags in Git commit messages.
Somewhat recently 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. Short of being part of a multi-part patch series and wanting to then find the patch series cover letter or look at any of the follow-up LKML discussions, including these “Link: ” tags often doesn’t provide much extra value but just waste time for those trying to find any added context.
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.
Dammit, I really hate those pointless links. I love seeing *useful* links, but 99% of the links I actually see just point to stupid useless garbage, and it *ONLY* wastes my time. AGAIN.
So 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.
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.”
He went on to clarify that he is in favor of the link tags when it’s for a multi-part patch series and wanting to find the cover letter. Indeed, this is one of my favorite uses for the link tag too.
“So I wish it at least had some way to discourage the normal mindless use – and in a perfect world that there was some more useful model for adding links automatically.
For example, I feel like for the cover letter of a multi-commit series, the link to the patch series submission is potentially more useful – and likely much less annoying – because it would go into the merge message, not individual commits.
Because if somebody is actively looking at a merge message, they are probably looking for some bigger picture background – or there’s some merge conflict – and at that point I expect that the initial submission might be more relevant.
Of course, most people don’t necessarily *use* the cover letter for a merge, and only apply the patches as a series, so it’s also less annoying for the simple reason that it probably wouldn’t exist in the git history at all ;)
Anyway, the “discourage mindless use” might be as simple as a big warning message that the link may be just adding annoying overhead.
In contrast, 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.
For example, since ‘b4’ ends up looking through the downstream thread of a patch anyway in order to add acked-by lines etc, I do think that in theory there could be some “there was lively discussion about this particular patch, so a link is actually worth it” heuristic.
In theory.
And honestly, even if the discussion ends up being worthless, I do suspect I would be a lot *less* annoyed by a link that at least leads to some _thread_ (and not just the acked-by emails that already got gathered up), rather than just leading to an email that was applied and nobody really had any input on.
At least at that point I’d feel like there’s something real there.
And yes, as always, I realize that people think that patch submissions will get more email replies at some hypothetical _later_ date. But in practice, that seldom happens, because the downstream testing issues typically create new threads, not replies to original emails (and if they *do* react to the original email, we already can look up the commit easily, and the lookup goes the other way anyway).”
So next time you are submitting patches for the Linux kernel, make sure that any “Link: ” tags provide some added value and aren’t useless.
