9月6日，linux之父linus torvalds对git提交记录中“link:”标签的滥用现象表达了强烈不满。他指出，近期在linux内核开发过程中，大量补丁和提交频繁添加“link:”标签，但这些链接大多并未提供实质帮助，反而增加了评审负担。
在审查一个block模块的pull request时，Torvalds直言不讳地批评：许多所谓的“Link:”只是指向与补丁内容完全重复的信息，并未带来任何新的上下文或背景说明。他强调，只有当链接能提供额外价值——例如指向具体的bug报告、邮件列表讨论串，或系列补丁的封面信（cover letter）时，才值得加入。
https://www.php.cn/link/de7e76952411d036ca4b58ffcf37bfe7
尽管他承认，在处理多补丁提交系列时，“Link:”标签确实有助于追溯整体设计思路和原始讨论，但他明确反对在普通提交中机械套用这一格式。他表示今后将更加严格地审查含有无效链接的合并请求，甚至可能直接拒绝此类提交。
他还提出，未来若引入自动化工具，不妨探索使用AI技术来智能识别是否存在活跃的邮件讨论，并据此自动添加真正有意义的链接。他说道：“我欢迎有价值的链接，但现实中99%的链接都是毫无意义的垃圾，纯粹浪费时间。”
Torvalds呼吁所有Linux内核贡献者，在使用“Link:”标签时务必确保其能为代码审查、问题追踪或历史回溯带来实际帮助，否则应坚决省略。
原文如下：
该死的，这次提交明明带着那个充满希望的"链接:"参数，我本以为它能解释这个毫无意义的提交为何存在，但一如既往地，那个链接只是浪费我的时间——指向的又是那些老掉牙的信息。
我原本期待它能指向某个错误报告之类的东西，解释为什么我的最初反应是错误的。
别再搞这种垃圾了。别再添加浪费人时间的无用链接参数。
只有当链接包含*额外*信息时才添加。
该死，我真的讨厌这些无用链接。我喜欢看到*有价值*的链接，但实际看到的99%都指向愚蠢无用的垃圾，而且*只会*浪费我的时间。又一次。
所以我不打算合并这个请求，光是看到它就让我恼火。若真要我合并，请给出实质解释而非无用链接。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
没错，我正处于暴躁状态。感觉我的主要工作——实际上唯一的工作——就是处理合并请求，因此我极度厌恶这些自动添加的垃圾内容，它们只会让我的工作更难做。
“所以我希望至少有某种方式能阻止这种机械、无脑的使用——在理想情况下，还可以有一种更有用、自动添加链接的模式。
例如，我觉得对于多提交系列的封面信件来说，链接到补丁系列的提交记录可能更有用——而且也不会那么烦人——因为它会被加入到合并信息（merge message）中，而不是每一个具体提交中。
因为如果有人真的在查看合并信息，他们很可能是在查找更宏观的背景信息——或在处理某个合并冲突——此时我认为最初的提交可能就更相关。
当然，大多数人实际上并不会在合并时使用封面信件，他们只是把补丁作为一个系列应用，所以其实也没那么烦人，因为它根本不会存在于git历史记录里 ;)
总之，‘阻止无脑使用’可能就只是加个大大的警告，提醒大家：这个链接可能只会带来烦人的负担。
相比之下，一个‘完美’的模式可能是实现某种自动化——‘除非真的有实际讨论发生’。
不过我觉得这种模式可能太复杂，除非真的有人愿意探索用AI，因为他们的工作描述就是‘寻找AI的实际用途’。在如今的科技世界中，我相信确实有人这样定位自己的岗位。唉。
举例来说，既然‘b4’最终会浏览补丁的下游帖子以便自动添加acked-by等信息，我确实觉得理论上可以建立这样一个启发式模型：‘某个补丁有活跃的邮件讨论，所以值得加上链接’。
坦率地讲，就算这种讨论最终没有什么实质内容，我想只要这个链接至少指向某个帖子（而不是那些已经收集起来的acked-by邮件），我也会觉得没那么烦人，相比那种只是指向单封邮件、没人回复过的链接。至少这样我会觉得多少有点实际内容。
当然，一如既往，我也意识到有些人认为补丁提交邮件之后，以后或许会有更多邮件回复。但实际上，这种情况很少见，因为后续测试中的问题往往会创建新邮件，而不是回复原始邮件（而且即便有人真去回复了原始邮件，我们也可以很容易根据提交查找邮件，反过来也可以查到）。”
源码地址：点击下载
