Linus又开怼，Git提交乱加“Link:”标签：99%都是没用的，白白浪费我的时间

作为全球 Linux 的“终身仁慈独裁者”，Torvalds 一直亲自把控着内核的日常开发。但熟悉他的人都知道，他脾气火爆，常常毫不留情地在邮件列表里直接开怼一些工程师。当然，对于他来说，这也不是单纯的情绪宣泄，而是一种保持项目质量的方式。

最近，Linus Torvalds 又双叒叕在 Linux 邮件列表发火了？这一次，让他爆发的点是他发现 Git 提交/补丁里存在越来越多的“Link:” 标签——这些链接往往没什么用，只会浪费时间。

Torvalds 认为这是工程师很多自动添加的东西，其怒斥道——”我们能不能别再搞这种愚蠢的自动化了？“

无处不在的”Link：“标签为什么会被批？

其实在Linux 内核开发里，每个补丁都会通过邮件列表（LKML）来提交和讨论。后来在把这些补丁合并到 Git 仓库时，开发者常常会在提交信息里加上一些“元信息”，比如：

Signed-off-by:—— 谁写的 / 谁审核过

Reviewed-by:—— 谁审过

Acked-by:—— 谁确认过

而「“Link:” 标签」也是其中的一种。它的作用是：在提交里留一个链接，指向相关的邮件列表帖子、补丁系列、讨论串或 bug 报告，方便后来的人追溯。

问题在于很多开发者提交时，会自动加上一个“Link:”，但它只是指回到补丁邮件本身，而提交里其实已经包含了完整内容。

这样就等于“重复一遍”，没有提供额外信息，这使得审核的人点开之后会平白无故的浪费时间。

日前，LinuxTorvalds在处理一个 block 子系统的拉取请求时就直接拉取又撤回，并在评论里火气很大地说道：

“该死，这个提交里带了一个看上去挺有意义的‘Link:’ 标签，我还以为能解释清楚为什么会有这么一个莫名其妙的提交。

结果呢？

老样子，点进去就是一堆重复信息，白白浪费我的时间。

我本来以为它会指向某个 oops 报告，或者至少能告诉我为什么我最初的判断是错的。

拜托，别再搞这种垃圾了。别再加这种浪费大家时间的没用链接。

只有当链接里有额外的信息时，才值得加。

说真的，我特别讨厌这些没用的链接。我当然喜欢能提供帮助的链接，但我看到的 99% 链接，全是没意义的废话。它们只会浪费我的时间，再一次！

所以我没拉这个请求。光是要看这些东西我就很烦。如果你真指望我拉取，那就给我一个真正的解释，而不是这种废物链接。

没错，我就是在抱怨。我觉得我的主要工作——甚至可以说唯一的工作——就是努力搞清楚拉取请求的来龙去脉。正因为这样，我才特别痛恨这些自动加上去的垃圾，它们只会让我工作更难。

我把这个邮件抄送给了 Konstantin，因为这正好说明了为什么这种自动化机制是在添乱。而他上周还在为这玩意辩护。

能不能别再搞这种自动化蠢事了？”

Linus：不是不喜欢“Link:”，只是不喜欢没用的“Link:”

不过，被 Linus 点名的 Kernel.org 系统管理员团队一员的Konstantin 也没有直接反驳他的抱怨，而是反问了一句

不过，被 Linus 点名的 Kernel.org 系统管理员团队成员之一 Konstantin，并没有直接反驳他的抱怨，而是反问道：

“仅供参考，Link: trailers 默认不会被添加，维护者必须有意地加上 -l 参数。

你是希望它完全不起作用，还是更希望它只在 patch.msgid.link 这个域名命名空间下使用，以明确表示它只是一个来源（provenance）链接？”

对此，Linus 在发完脾气后，倒是能心平气和地继续讨论。

他补充说明，他并不是反对在所有邮件里都加Link:标签。对于多部分补丁系列，如果希望快速找到对应的封面邮件，他认为这些链接确实有价值，这也是他个人最喜欢的用法。

“我希望至少能有一种办法，能阻止大家这种毫无脑子的滥用——而在理想的情况下，最好还能有个更有用的自动加链接的机制。

举个例子，如果是多提交系列补丁的封面邮件，把它的链接放到合并信息里，可能更有用，也没那么烦人。因为当有人在看合并信息时，他们很可能就是在找更宏观的背景信息，或者在解决合并冲突，这时放上初始提交的链接会显得更有相关性。

当然，大多数人并不会在合并时用封面邮件，而是直接按系列应用补丁。所以这样一来，这个链接也更「无害」——因为它可能根本不会出现在 Git 历史里”，Linus 说道。

Linus 还提到，可以通过一些机制来减少“无脑加链接”的行为，比如在添加链接时给个大大的警告，提示：“这个链接可能只是徒增负担”。

不过，他认为更“完美”的做法，或许是有某种自动化检测模型，只有在确实有讨论时才加链接。

Linus 开玩笑说道，虽然这种模型可能太复杂，但如果有人“岗位职责里就写着‘寻找 AI 的实际用途’”，那或许可以用 AI 来做这件事。

「在今天的科技圈，我想这样的岗位确实存在。比如，工具b4本来就会在补丁下游讨论串里扫描，以收集 acked-by 等信息，那么理论上也能根据“是否有热烈讨论”来判断一个链接是否值得保留。」

即便讨论本身价值有限，他也宁愿看到一个能指向整个讨论串的链接，而不是仅仅跳转到一个没人回应的单封邮件。至少那样能让他感觉“这里确实有点实质内容”。

最后，Linus 还补了一句：“人们常以为补丁提交会在未来某个时候收到更多回复，但现实中几乎不会。因为测试相关的问题通常会新开线程，而不是回复原始邮件。即便有人真回复了，Git 里本来就能查到提交，查询方向其实是反过来的。”

对于这一现象，也有不少工程师觉得问题还是出在了 Linux 用邮件列表的工作方式上，“迟早他得意识到，问题在于邮件列表的工作方式。本身就很滑稽——尤其是当那个对邮件列表里的封面邮件和文本格式抱怨连连的人，恰好又是为了处理这些问题才创造了 Git。”

总而言之，今后提交 Linux 内核补丁时，记得“Link:” 标签必须带来额外价值，不要乱加无用链接。

参考：

https://lore.kernel.org/all/CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com/

https://lore.kernel.org/all/20250905-lovely-prehistoric-goldfish-04e1c3@lemur/

https://www.phoronix.com/news/Linus-Torvalds-No-Link-Tags