BitKeeper、Linux 和许可纠纷：Linus 如何在 14 天内写出 Git

git linux Linus Torvalds| 2024-05-25

2005 年 4 月 3 日，Linus 发布了 Linux 内核候选版 2.6.12-rc2。候选发布版本身并不引人关注–用Linus 的话说：”diffstat 输出说明了一切：这是许多非常小的改动，即大量的小清理和 bug 修复。- 但它的重要意义在于：Linux 内核的最后一个非 Git 版本。

BitKeeper

在使用 BitKeeper 之前的头十年，Linux 内核的版本控制工具一直由 Linus 自己选择。这个系统是这样工作的：开发者向Linus信任的几个副手提交压缩包和补丁。经过审核后，通过审查的补丁会被送到Linus那里。最后，Linus本人会手动将它们纳入自己的源代码树，然后剪切发布。

当然，”Linus版本控制服务 “并不是一个完美的产品。1998 年，当 Larry McVoy 在 Linux 内核邮件列表上首次勾勒出 BitKeeper 背后的想法时，他写道：”很明显，我们无畏的领导者 [Linus] 目前有点超负荷工作，所以补丁可能会丢失。

虽然这种手动工作流程在今天看来很野蛮，但在当时，Linus认为这种工作流程比 CVS 等替代方案更优越。很久之后，当 Linus 于 2007 年在谷歌发表关于 Git 的演讲时，他提到了自己的一个核心设计原则：”WWCVSND “或 “CVS 不做什么？当然，这种憎恨自然也延伸到了 SVN 上；在同一场演讲中，他还笑着说：”如果听众中有 Subversion 用户，你们可能会想离开。我对 CVS 的憎恨意味着我认为 Subversion 是有史以来最无意义的项目。有一段时间，Subversion 的口号是 CVS done right 或类似的东西。如果你从这个口号开始，你将无路可走。这就好像，CVS 没有办法做对。”

Linus对 CVS 的批评核心在于它的集中性。鉴于 Linux 开发人员多达数百人，Linus认为每个人都拥有自己独立的版本库副本并在此基础上开发自己的分支至关重要。这既减轻了离线工作，又有助于内部政治；每个开发者都可以自由地向自己的版本库提交任何他们想提交的内容，然后就有机会说服社区相信他们的修改是有价值的。这就避免了由一组拥有提交权限的贡献者把关唯一的版本库。

BitKeeper 与 CVS 形成了鲜明的对比。在前面提到的 1998 年 BitKeeper 的推介中，Larry McVoy 勾画了一个系统，虽然让人想起我们今天对源代码控制的看法，但在当时却是完全不同的。麦克沃伊写道

让这一切得以实现的机制是一个分布式源代码

管理系统。

该系统的主要特点如下

– 每个人都有一个资源库（与只有一个资源库相比CVS 模式形成鲜明对比）

– 更改可以作为 “超级补丁”（也称为变更集。变更集只是一个补丁文件，其中包含

* 所有修改，一次分成一个修订版

* 显示补丁应用位置的标识符

一个标识符，显示补丁应在树中的哪个位置打上（如果不是最新版本，补丁会打不上补丁发送者一样是最新的，补丁就会失败）

* 更改的所有修订历史

* 元数据，如路径名更改、符号标记(如 alpha2 或 linux-2.1.133）等。

– 一个新概念，称为开发线（LOD）。

从逻辑上讲，它是一个分支，但并不需要在分支上。

补丁可以（也将会）成为自己的 LOD。您可以执行操作，比如 “将此应用到主干”。

后来，Linus对 BitKeeper 给予了高度评价，认为它改变了他的观点，并激发了 Git 的灵感：”BitKeeper 不仅是第一个让我觉得值得一用的源代码控制系统，也是一个让我明白为什么要使用它们以及如何才能真正发挥作用的源代码控制系统。因此，尽管从技术角度看，Git 与 BitKeeper 有很大很大的不同（这也是我的另一个设计目标，因为我想清楚地表明它不是 BitKeeper 的克隆版），但我们在 Git 中使用的很多流程都直接来自于我们从 BitKeeper 中学习到的流程。(这里的措辞有点别扭，因为它来自前面提到的 Google 现场演讲）。

许可证

Linus 本人对 BitKeeper 评价很高，但他在 2002 年决定在 Linux 内部使用该工具时，却在 Linux 内核邮件列表上引发了大规模的火焰战争。

为什么是火焰？Larry McVoy 创建 BitKeeper 时，是将其作为商业闭源工作（BitMover）的一部分。虽然人们可以使用 BitKeeper 的免费社区版本，但这是有限制许可的。

摘自 BitKeeper 维基百科条目：”BitKeeper 的’社区’版本的许可证允许开发者在开源或自由软件项目中免费使用该工具，条件是这些开发者在使用 BitKeeper 的一年时间内没有参与竞争工具（如 Concurrent Versions System、GNU arch、Subversion 或 ClearCase）的开发。无论竞争工具是免费的还是专有的，这一限制都适用”。

就连最后一位真正的黑客和自由软件布道者理查德-斯托尔曼（Richard Stallman）也加入了这一行列：”Bitkeeper 许可证的精神就是鞭子的精神。它是这样说的：’你无权使用 Bitkeeper，只有我们可以取消的临时权限。感谢我们允许你使用 Bitkeeper。心存感激，不要做我们不喜欢的事情，否则我们可能会取消这些特权。……对这种精神的愤怒就是自由软件运动的原因。”

但Linus的观点要务实得多；从他的角度来看，他只想要最好的工具，不管它来自哪里。2007 年，他说：”我对（BitKeeper 的许可安排）很满意，因为坦率地说，就我而言，我做开源软件是因为我认为这是做软件的唯一正确方式。但与此同时，我也会使用最合适的工具，坦率地说，BitKeeper 就是这样的工具”。

然而，这种不和谐的婚姻并没有持续多久。

2005 年，Linux 内核开发者之一安德鲁-特里吉尔（Andrew Tridgell）违反许可证规定，对 BitKeeper 进行了反向工程，从而 “可以在不同意 BK 许可证的情况下从 BK 树上 pull 东西“，他的行为迫使人们关注这一问题。在 Tridgell 看来，这完全符合道德规范；“在编写这个工具时，我根本没有使用 BitKeeper，因此根本不受 BitKeeper 许可证的约束”。

拉里-麦克沃伊不同意。最初，Linus站在他这一边：

“Larry 完全同意有人编写免费的替代品。…拉里不同意的是，有人通过逆向工程来编写免费的替代品。拉里有一个非常明确的道德立场：’你可以和我竞争，但你不能搭我的便车。自己解决问题，诚实竞争。不要盯着我的解决方案来竞争。这就是 BK 许可证的含义。它说：’别搭我的顺风车，你这个白吃白喝的家伙’。我（Linus）无法反驳这一点。”

就Linus而言，他在三个月的时间里一直试图扮演和事佬的角色。(如果说有什么不妥的话，他今后的言论似乎更多地是在暗示他对安德鲁的不满，而不是对拉里的不满）。但最终还是无法调和这些分歧。

2005 年 4 月 6 日，Linus向 Linux 内核邮件列表发送了一封电子邮件，邮件主题为 “内核单片机传奇……”，由此拉开了改变整个行业的序幕：

“好的，正如很多人已经知道的那样，在过去的一两个月里（感觉时间更长），我们一直在努力解决 BK 使用方面的冲突。但结果并不理想，因此，内核团队正在寻找替代方案”。

他拿这段历史开玩笑说：”我选择的 BK 并不是完全没有冲突的（’真的假的？请告诉我！哦，你是说我们曾经有过的千兆字节的火焰？

尽管结果不尽如人意，但Linus在回顾这段时光时仍满怀深情：

事实上，BK 所产生的影响之一就是从根本上改变了我们（尤其是我）的工作方式。这包括细粒度的变更集跟踪，也包括我如何最终信任子维护者来处理更大的事情，以及不再需要逐个补丁地工作。因此，在 BK 的三年时间绝对没有白费：我相信它让我们以更好的方式做事，而我正在考虑的事情之一就是确保这些事情继续有效。

所以我只想说，我个人对 BK [BitKeeper] 和 Larry 都很满意。虽然没有成功，但它确实对内核开发起到了很大的作用。我们会解决暂时的问题，那就是必须找出一套工具，让我们能继续做 BK 允许我们做的事情。

Linus在度假

实际上，当他在 4 月 6 日向邮件列表公开发布分手消息时，Linus 已经在努力工作了。三天前，就在 2.6.12-rc2 发布之后，他停止了 Linux 内核的开发工作，转而全力寻找 BitKeeper 的替代品。

Linus的目标是 “在两周内找到可用的东西”。作为 4 月 6 日那封电子邮件的一部分，他宣布：”我将实际离线一周（就当是一次普通的 “Linus去度假 “活动），我只是想请继续维护 BK 树的人至少也要确保他们能把结果作为（单个）补丁发送给我，因为我最终还得通过其他方式进行合并。

Linus的邮件清楚地表达了他的紧迫感；毕竟，在他解决这个问题之前，下一个 Linux 内核的发布将被阻止。

在 4 月 7 日的一封电子邮件中，他甚至指出，在最坏的情况下，Linux 内核甚至有可能转向集中式版本控制系统：”注意！我讨厌集中式 SCM 模式，但如果迫不得已，而我们又无法在短时间内（即一两个月）实现合理的并行合并，我会在一个只有几个提交者的可信站点上使用类似 SVN 的系统，至少尝试将合并工作分配给几个人，而不是让我来节流。”

虽然现在回想起来，我们对结果已经很清楚了，但从当时的邮件来看，编写一个定制的版本控制系统远非必然。在从 4 月 6 日第一封邮件到 4 月 12 日最后一封邮件的 205 封邮件链中，有很多关于其他开源替代方案的讨论–Monotone、GNU arch、Bazaar-ng、Darcs–其中一些工具的创建者跳出来为他们的项目鼓与呼。

(就连 Subversion 开发人员也发表了 “请停止纠缠 Linus Torvalds 有关 Subversion 的问题 “的帖子）。

主要的考虑因素，尤其是 Linus，似乎是这些工具的整体性能。总之，在所有 205 封邮件中，有很多关于各种工具的性能和效率的讨论。

每个人心中最大的疑问似乎都是：现有的任何工具都能用于像 Linux 内核这样规模的项目吗？

4 月 8 日，在他发出第一封邮件的两天后，也是在他正式开始工作的五天后，Linus分享了一个更新：”与此同时（因为单音真的那么慢），这里有一个对你和任何疯狂黑客的快速挑战：如果你想玩一些非常讨厌（但也非常非常快）的东西，请看看 kernel.org:/pub/linux/kernel/people/torvalds/”。

Git 就这样诞生了。

Git 的第一行

当我们听说Linus用两周时间就写出了最初的 Git 时，有一点值得注意：当我们今天想到 Git 时，我们想到的是面向用户的命令和整体工作流程，但当时的目标和任务却大相径庭，范围也有限得多。

当不同的人在邮件列表中争论各种工具和方法的优劣时，有一个人写道，他大致描述了当时的需求：”只要不是慢得可怜，慢一点也没关系。临时解决方案的目的只是让补丁流程重新上线”。

Linus最初的 Git 更像是一个内容可寻址的文件系统，而不是一个成熟的源代码控制系统。以下是他在另一封邮件中的解释：

(*) 我称之为 “提交”，但其实简单得多。它其实就是 “我现在有了<这个目录状态>，我从<以前的目录状态集合>中找到了这个目录状态，原因是<理由>”。

这就是我们的设计。”git “并不关心合并之类的事情。你可以用任何 SCM 进行合并。git “所做的只是跟踪目录状态（以及如何达到该状态），而不是其他。它不会合并，也不会做任何事情。

因此，当你 “拉取 “或 “推送 “一个 Git 压缩包时，你得到的是目标中所有目录状态的 “联合”。HEAD 是 “目录状态之海 “的一个指针，但要想把两个目录状态合并在一起，还真得用点别的办法。

当讨论到在电子邮件线程中挑选工作流程和移动提交时，Linus从他正在构建的客户端中将其排除在外。

总而言之，Linus评论说：”‘Git’真的很简单，四天就写完了。其中大部分时间并不是在实际编码，而是在思考数据结构”。

这句话后来被他反复引用，有时也会被断章取义，但却不无道理–当时的数据结构选择是Linus所写代码中最新颖的部分。在Linus分享了他的前几次提交之后，大家并没有讨论工作流程（这也是今天人们在讨论 Git 时最常想到的）。相反，大多数讨论都围绕着我们现在认为理所当然的架构：Git 与文件系统的直接对接，以及基于哈希值的方法来分辨哪些文件发生了改变（并确保数据完整性）。

少数人主张使用 SQL 来存储更改。以下是Linus关于后者的一次经典交流：

> 为什么不用 sql 作为后端，而不用目录树？

因为它很烂？

我自己就能想出几百万种方法来降低运行速度。请提出加快速度的方法。

Linus

但也有一些人看到了这一愿景，并迫不及待地开始了 Git 的开发工作。就在Linus请大家查看他目录中的改动的同一天，一些人发回了在他的基础上构建附加功能的脚本。

开始工作两周后，即 2005 年 4 月 17 日，Linus给电子邮件列表发了一封邮件：“第一次真正意义上的内核 Git 合并！”

未来一瞥

在所有这些事件发生近二十年后，再读最初的电子邮件链，最令人满意的是看到了作者们当时不知道的未来的蛛丝马迹。

在评估 “单调 “这一源代码控制替代方案时，一位用户写道

有一点令人讨厌的是，monotone 似乎没有网络界面。我以前在追踪 bug 时经常使用 bk 界面，因为打开一个网页浏览器窗口，点击文件的修订版本，阅读签入注释等，速度非常快。有谁知道是否正在开发网络界面？

当时，用于源代码控制和代码审查的网络用户界面刚刚流行起来；在谷歌，Guido van Rossum 在 Mondrian 中构建了他们第一个专门的网络代码审查工具。而在这封邮件的两年后，GitHub 就成立了。

电子邮件链中关于性能的来来回回的讨论也是一种讽刺。

在过去，人们曾对 Git 在基于网络的文件系统支持下的性能表示担忧；对于谷歌（FUSE）和 Meta（EdenFS）这样的巨头来说，这些基于网络、可感知源代码控制的文件系统是他们在庞大的单核系统中持续扩展源代码控制和构建的关键部分。

而当时激励Linus编写 Git 的核心问题–现有的版本控制替代方案都没有足够的性能来支持 Linux 内核 repo 的大量历史记录和提交吞吐量？

几年后，当 Meta 出于同样的原因将其主仓库从 Git 迁移到其他版本控制工具时，这个问题又重演了。

当然，当时参与最初的 “内核 SCM 传奇…… “邮件链的人并不知道这一切。

Linus的评论强调，他明确地把源代码管理看作是其他工具的领域，这些工具随后会与 Git 接口。

当我们回顾历史时，往往会将其浪漫化为灵感的突发。但是，Git 的诞生却展示了更为残酷的发明现实：对许可证的分歧慢慢升级；需要一个零碎的备份解决方案来疏通工作；然后，不是由发明者，而是由一个社区领导，经过年复一年的持续打磨和迭代。

后记

最终，BitMover 确实开源了 BitKeeper。在 2016 年 BitMover 发布公告时，一位 HN 评论员（现任 Oxide 首席技术官的布莱恩-坎特里尔）留下了一段精彩的评论，为整个事件画上了一个完美的句号：

“极具讽刺意味的是，Larry 是 Sun 公司最早倡导开源操作系统的人之一[1]–他认为，当 Sun 公司最终集体想通并付诸实施时（2005 年），已经晚了十年甚至更久。[2]因此，一方面，你可以把 BitKeeper 的开源故事看作是希腊式的悲剧：Larry 为 Sun 提出的 “源代码软件”[3] 的每一个理由都适用于 BK，就像适用于 SunOS 一样 — 甚至是同一个技术专家（Torvalds）领导了开源替代方案！你现在可以对 BK 和 Larry 说 “为时已晚”，就像 Larry 在 2005 年对 Sun 说的那样，但我也认为这代表了 “赢家 “和 “输家 “的强行对立。相反，我愿意相信，illumos 社区（SmartOS、OmniOS 等）的持续创新证明，开源软件永远不会太晚–开源社区（就像城市一样）可以很小，但充满活力，为其支持者发挥关键作用。在另一个宇宙中，我们可能会在 SunOS 上运行 BK，而不是在 Linux 上运行 Git 吗？当然有可能，但是能够在开源illumos上运行开源BK也是一件非常了不起的事情；两个创新系统的未来已经得到了保证，尽管所花的时间比大家希望的要长一些。

另一位 HN 用户 “luckydude”–拉里-麦克沃伊本人–发布了回复。