LWN：关于 link tag 的规则！

关注了就能看到更多这么棒的文章哦～

A policy for Link tags

By Jonathan Corbet
September 11, 2025
Gemini flash translation
https://lwn.net/Articles/1037069/

Git 源代码管理系统存储了大量关于代码变更的信息——但它并没有涵盖未来开发人员在调查特定变更时可能感兴趣的所有内容。仓库中的提交（commits）通常是（有时是漫长的）讨论的最终结果；这些讨论往往会导致代码发生变更，而这些变更并未在变更日志（changelog）中得到解释。多年来，许多维护者一直遵循一个惯例，即在提交中应用一个 Link 标签，指向该变更在邮件列表上的发布。然而，Linus Torvalds 一段时间以来一直在表达他对这一惯例的不满，现在看来，它的时代似乎即将结束。

某些源代码管理系统能够通过为工作分配一个“变更 ID（change ID）”来跨多个版本跟踪变更。然而，Git 并没有这样做，因此内核社区（kernel community）无法轻松查看补丁（patch）的历史记录。在 2019 年内核峰会（Kernel Summit）之前的一次讨论中，Shuah Kahn 询问社区是否应该采用某种变更 ID 惯例来跟踪进入内核的工作。一个月后，Doug Anderson 提出了类似的建议。随后的深入讨论并未导致变更 ID 的采纳，但它们确实带来了一个相关的变更。

具体来说，Thomas Gleixner 建议使用一个 Link 标签，其中包含每个提交在邮件列表上发布的存档 URL：

真正有用的是当提交（commit）包含 Link 标签时：

https://lore.kernel.org/lkml/$MESSAGE-ID

如果提交者在其 V(N) 版本提交的附函（cover letter）中提供指向 V(N-1) 版本的相同链接：

https://lore.kernel.org/lkml/$MESSAGE-ID-V(N-1)

如果是一个单个补丁（patch），链接可以放在补丁本身中，在 — 分隔符之后。这使得快速查找历史记录成为可能。

Link 标签并非新事物；它首次出现在内核仓库中是在这个 2011 年的提交中。该提交以及其他 56 个包含 Link 标签的提交，都被纳入了 2.6.39 版本。最初，此标签主要用于 x86 和核心内核子系统（core-kernel subsystems）的提交，每个版本中约有 300 到 500 个提交使用。如下图所示，Link 标签的使用量随时间缓慢增长，直到发生了某些事情：

在 5.2 开发周期中途发生的“某些事情”，当然就是上述的讨论。当时似乎达成了广泛共识，认为在提交中添加 Link 标签会有所帮助。Kees Cook 发布了一个 Git 钩子（hook）配置，该配置会在使用 git am 应用补丁时自动添加标签。Linus Walleij 更新了内核文档，建议使用此钩子；后来，b4 工具（b4 tool）也增加了一个用于添加 Link 标签的标志。Link 标签的添加量相应增长；在 6.16 版本中，有 11,030 个提交（占总数的 75%）包含了 Link 标签。

（值得注意的是，Gleixner 建议的另一部分——即每当补丁系列（patch series）更新时都包含一个指向之前发布的链接——尚未被广泛采纳，尽管许多开发人员确实包含了这些链接。这些反向链接非常重要，任何 LWN 内核作者都会证明，如果你希望查看变更在多次迭代中的历史记录。）

在 2019 年的讨论中，Torvalds 对包含 Link 标签的想法不温不火；他当然没有反对，并表示这比试图创建某种变更 ID 要好。然而，到了 2022 年，他开始抱怨这些标签：

我*真心*希望 tip 树（-tip tree）能有更多指向实际问题报告和解释的链接，而不是指向补丁提交的链接。

前者包含实际问题。后者只包含提交中已有的信息，而“Link:”几乎没有增加实际价值。

这种抱怨在这些年变得越来越普遍，最终在关于虚拟文件系统层（virtual filesystem layer, VFS）和io_uring 补丁集（io_uring patch sets）的讨论中，演变成了措辞强烈的指责。核心问题始终未变：他不喜欢当他循着 Link 标签中的 URL，希望了解更多有关该变更的信息时，却只发现变更日志（changelog）中已有的相同信息。这减慢了他的工作流程，并增加了他的不悦程度。

许多开发人员在这些讨论中试图为这些标签的使用辩护。Christian Brauner 表示：“我关心的是我可以在主线（mainline）上使用 git log，找出那个补丁在哪里讨论过，并通过 b4 或其他工具下载讨论内容，而无需搜索 lore。”Konstantin Ryabitsev 指出，通过搜索存档来查找补丁提交并非总是容易的。Jens Axboe 表示，这些标签有助于找到补丁系列（patch series）的附函（cover letter），也有助于发现补丁应用后发生的讨论。Greg Kroah-Hartman 主张保留这些标签，称“它们对于那些需要经常深入探究我们的 git 分支的人来说非常有效。”

然而，Torvalds 对这些论点不为所动，坚定反对使用 Link 标签，除非链接背后有“有趣”的内容。在最近的讨论中，Axboe 多次要求 Torvalds 就 Link 标签的实际规则发表正式声明（并建议召集 LWN进行总结）。Torvalds 似乎已在 6.17-rc5 版本（6.17-rc5 release）的发布说明中回应了这一请求：

所以，如果一个链接不包含任何额外相关信息，就根本不要添加它，不要抱有明天它会变得有用的错误希望。

让“Link:”标签成为值得庆祝的东西，而不是因为它们毫无价值并浪费人们时间而受到诅咒的东西。

拜托了？

许多维护者不太可能为此庆祝，因为他们不得不停止自动添加 Link 标签，并对每个提交思考这样的标签是否“有趣”。但他们可以庆祝的是，投入这项工作的时间将节省回复来自首席企鹅（Chief Penguin）的抱怨邮件的时间。虽然这项新政策在维护者中可能不完全受欢迎，但至少现在，围绕这些标签的使用有了一个接近实际的政策。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～