11月8日，网红仲尼突然登上热搜，这次不是和外籍老婆卡琳娜的感情问题，而是有消息曝出他已经去世，原因是和老婆一起去巴厘岛庆生，冲浪时两人不幸被卷走，外籍老婆成功救出并送往医院，没有受到重伤。而报道称这位中国籍男子遗体已经找到，家人正赶往巴厘岛。网友听后一脸惊恐：不会吧？会不会认错人了，赶紧出来辟谣吧！
目前，官方给出的消息虽然没有曝出名字，不过已经有人说死者就是仲尼，而他社交平台最后的信息，确实是生日消息。
还有网友这几天在机场看到仲尼和卡琳娜出现在巴厘岛机场，两人疑似在那边度假。
目前，网友听到这个消息都非常震惊，纷纷留言说：
仲尼？不会吧？俩人都溺水了？真的不敢相信，假的吧！
男方出轨不假，对卡琳娜管控也很严，但是他们的女儿怎么办，真不希望这是真的。
如果是假的，赶紧出来辟谣吧，吓死人了啊！
还有人说：现在巴厘岛正是雨季，还跑去冲浪，这不是找死么？两人怎么回事啊，不会是殉情吧？
当初，仲尼因为英俊的外形，忧郁的气质在“非常完美”一炮走红，成为无数女孩心中的男神。直到他娶了美丽的外籍老婆卡琳娜，网友们对他更是羡慕不已。
去年，网上曝出他出轨的消息，还有对妻子卡琳娜的控制欲引发了网友的不满，但谁也没想到会以这样的方式离开。
希望这个消息是假的，本人到现在没出来辟谣，昨天开始就没有任何动态，确实令人揪心。
感谢安德鲁-特里吉尔（Andrew Tridgell）没有让内核受困于专有的源代码控制。从长远来看，坚持原则可以让世界变得更美好，即使一开始会惹恼别人。
内核并没有被 “卡住”；莱纳斯归根结底是个务实的人，用它来做集成工作没问题。是否改用开源解决方案的问题最终会被再次提出，但在当时，它做了它应该做的事情。
感谢您分享这篇有趣的文章。
Bitkeeper很不错，我对它的总体看法与Larry McVoy如出一辙：我希望他能将其开源，让他的坚果运行类似 github 的东西，但用于 Bitkeeper，并希望它能存活下来。
我和他只有过一次交集。二十世纪初，我为 TortoiseCVS 贡献了少量代码。(比如改进了安装程序，添加了一个调用工具的方法，该工具可以合理地显示`.doc`和`.rtf`文件的差异）。我有一个新的、非常小众的硬件，我对它很感兴趣，并想在 Linux 内核中添加对它的支持。在阅读了他的 Bitkeeper 许可协议条款并打算维护我的 TortoiseCVS 补丁之后，我给他发了一封邮件，问他我是否可以使用 Bitkeeper。他告诉我，我看起来不像是在做版本控制软件的生意（我不是！），并让我继续使用，但如果情况有变，请通知他。
我现在一直在用 git，因为它已经足够好了，我不应该把我的 “创新代币 “花在这个领域。但我还是宁愿用 bitkeeper、mercurial 或 fossil。我只是无法证明，与众不同会给协作带来多大的影响。
就像我告诉很多人的那样，去看看 Jujutsu 吧。它的用户界面很有 Mercurial 风格，但比 Mercurial 更好（首席开发人员和我在 Mercurial 上共事多年），Git 是它主要支持的后端之一。我已经全职使用它快一年了。
我很想使用 jujutsu，它似乎是个不错的模式。不过我觉得，如果全世界都开始用一家公司的老板和一个 CLA 来构建顶级软件，那结果会很糟糕。
我希望 CLA 有一天会消失。
请注意，CLA 并不转让版权，因此从版权角度来看，”单一公司所有者 “并不准确。
从 “只有一家公司有权任意更改许可 “的角度来看，它是准确的。
不，这不准确。谷歌的 CLA 并非如此。(虽然也有其他 CLA 与您描述的内容比较接近）
(更新：* 虽然我不懂法律，但你应该读读孩子的评论和 CLA 本身，然后自己做出判断。https://cla.developers.google.com/about/google-individual。我的其余评论与前一段基本无关）。
另外，虽然我不是专业人士，但据我所知，任何人都可以 fork`jj` 并销售基于 jj 的专有产品（并且可以在几乎任何他们喜欢的许可下发布，几乎没有任何限制），因为它目前是 Apache 许可，但这与 Google CLA 无关。
让我对我不知道的事情进行更大胆的猜测。以下是我的猜测。
一种解释是，谷歌倾向于在 Apache 下发布他们的项目，因此没有必要要求人们将版权转让给谷歌。通过在 Apache 下发布你的作品，你已经给了谷歌（或其他任何人）它需要的所有权利。
据我所知，谷歌个人 CLA 的主要目的是让你签署一份声明，声称你拥有自己作品的权利，并且没有将这些权利转让给你的雇主。
> 授予版权许可。根据本协议的条款和条件，您特此授予 Google 和 Google 发布的软件的接收者永久的、全球的、非排他性的、免费的、不可撤销的版权许可，以复制、制作衍生作品、公开展示、公开表演、再许可和分发您的贡献和此类衍生作品。
这是一个比 Apache-2.0 更为宽松的许可协议（更不用说适用于谷歌也适用该 CLA 的作品的其他许可协议了）。该条款意味着，谷歌可以无视 Apache-2.0 的条款，转而在这种更为宽松的许可下使用作品，而其他人则受 Apache-2.0 的约束。换句话说，他们可以对代码为所欲为。其他人当然可以在专有产品中使用该代码，但他们不能无视许可证条款。
“许可 “并不意味着 “为所欲为”。Apache-2.0 除其他规定外，还要求保留许可证声明、
(请注意，”和接收者 “条款并不意味着其他人可以无视许可条款，因为他们仍需遵守谷歌在其分发的软件上发布的任何许可条款，无论该许可是 Apache-2.0 还是某种专有许可）。
因此，我坚持认为，”只有一家公司有权任意更改许可条款 “是一个基本准确的总结/概括。或者，如果你愿意，”有一家公司有权无视许可条款”。
说得好，你确实可以认为 “有一家公司有权无视许可条款 “是正确的。谢谢你的详细说明，我在评论中加了注释。
我仍然不确定这是否真的与 Apache 许可证有关，但我觉得自己没有资格争论这个问题。
我想我反对的 “稻草人 “说法是，有些人认为你把版权转让给了谷歌（你没有），但这与你的说法不同。
谢谢，感谢你的跟进和编辑。版权转让协议比 CLA 更糟糕，但我并没有说 Google CLA 包含版权转让。
对于 Apache 许可来说，版权转让比版权许可更不重要，但人们使用 Apache 而不是 MIT 或公有领域仍有其原因，而且 Apache 许可确实包含了一些人们关心的保护措施。
关于您的编辑：
> 据我所知，谷歌个人 CLA 的主要目的是让你签署一份声明，声称你拥有自己作品的权利，并且没有将这些权利交给你的雇主。
开发者原产地证书（DCO，如果你使用 “Signed-off-by: Your Name <email@example.org>”一行，你签署的就是该证书）也有同样的目的，但它不是 CLA，也不会引起同样的问题。法律部门一般不会担心开发人员签署 DCO，而许多法律部门则会理所当然地阻止或限制开发人员签署 CLA（即使他们在其他方面对开发人员为开放源代码做出贡献没有意见）。
https://martinvonz.github.io/jj/latest/tutorial/
https://github.com/martinvonz/jj
看起来确实是一个有趣的观点）
我是 BitKeeper 的忠实用户。
在我看来，Git 几乎就是对 BitKeeper 的彻底重写。Gitk 和 git-gui 本质上就是 BitKeeper 图形用户界面的克隆。
我不明白你为什么还要继续用 BitKeeper。
我想我的记忆可能是因为 BitKeeper 是我的第一个 DVCS。我从来不是它的忠实用户。
我是在管理团队的 CVS 服务器时接触到 BitKeeper 的。在我的下一个团队中，我们转用了 svn，从开发者的角度来看，它总给人一种 cvs 更好用的感觉，但当管理服务器的工作落到我头上时，我却觉得它比 CVS 好用多了。从开发者的角度来看，我觉得 BitKeeper 会更好。
在我的下一个团队，我们使用 mercurial。无论是作为开发人员还是开发基础架构管理员，我都非常、非常、非常喜欢 mercurial。在 Windows 上，它也比 git 或 BitKeeper 糟糕得多。
上次我为一个新团队做决定时，mercurial 和 git 是不二之选。我选择了 git，因为它显然是世界上最受欢迎的工具，而且这样我也不需要花费太多精力就能让新团队成员尽快适应。
说了这么多……我之所以直接比较 git 和 bitkeeper，是因为当时 bitkeeper 很成熟，而 git 显然还不成熟。然后我就把它和 mercurial（我现在还是更喜欢 mercurial）和 fossil（同上）混为一谈了。你对 BK 的看法可能完全正确。
从概念上讲，Git 的功能更强大。但我记得 bitkeeper CLI 的界面要合理得多。
它有自己奇怪的怪癖，有时会显示它是一个有很多有趣格式行的单一文件的幌子。我们与它只是时间上的隔阂，只有熟悉的东西才能让人真正憎恨。
我不会把化石列入协作清单，因为它并不是一个真正的协作工具，或者说，协作存在障碍，比如为每个化石库创建一个用户名。在我看来，这是一个巨大的障碍。如果能有一个通用的认证身份，可以在所有地方使用，那就更好了，但现在还没有实现。
顺便说一句，mercurial 似乎比 git 更有优势，而且对大型版本库的支持似乎是由 facebook 提供的，所以在 facebook 转向 git 之前，mercurial 仍将继续存在。
Facebook 并没有真正使用 vanilla mercurial，而是使用了自己面向规模的 rust fork。它的开源版本是 “sapling”。
你可以拥有一个版本库，并通过 “登录组 “将所有其他版本库链接到该版本库。
https://www.fossil-scm.org/home/doc/trunk/www/caps/login-gro…
它是开源的，采用 Apache 许可证 2。请访问 https://www.bitkeeper.org/
从历史来看，https://github.com/bitkeeper-scm/bitkeeper 在多个层面上都很有趣。
非常棒的读物！我喜欢这本书。
这是我目前所知的最完整的 git 历史。出类拔萃！
我希望能读到更多类似的历史文章，了解那些帮助我们塑造世界的软件。
> 这是目前我所知道的最完整的 git 历史。
在看到你的评论之前，我本来没打算读这个故事。我知道 BitKeeper 的摘要和后果，但这本书太详细了。谢谢！
http://folklore.org 有很多关于苹果的好故事。
+!很好的读物。这个领域很年轻，正在加速发展。历史相当紧凑。这样的文章很有价值。
同上。这真是一篇不错的文章！
> 我最大的遗憾不是钱，而是 Git 作为 SCM 的借口太糟糕了。它的模式是一个 tarball 服务器，这让我很抓狂。就连 Linus 也向我承认这是一个糟糕的设计。它做了他想做的事，但他想做的事并不是全世界都该做的事。
为什么是蹩脚的？怎样做会更好？
编辑：@luckydude 感谢您慷慨地回应了我的提示，尤其是几乎是瞬间的回应，哇 🙂
我与 Git 的问题
– 不支持重命名，只能猜测
– 没有编织。在此不做赘述，假设有人在某个分支上添加了 N 个字节，然后该分支被合并了。这 N 个字节会被复制到合并节点中（是的，我知道，git 会查找并删除这些字节，但这只是解决问题的一个缓慢的 “创可贴”）。
– 注释是错误的，如果我在分支上添加了 N 个字节，而你合并了它，那么（除非现在这个问题得到了解决）在合并节点中就会显示你是 N 个字节的作者。
– 整个资源库只有一个图形。这会导致多个问题：A) GCA 是版本库的 GCA，如果像 BitKeeper 那样每个文件都有一张图，它可能会与文件的 GCA 相去甚远。B) 调试是颠倒的，你需要从变更集开始向下钻取。在 BitKeeper 中，由于每个文件都有一个图形，假设我有一个 assert() pop。在该文件上运行 bk revtool，找到断言，然后查看断言之前有哪些变化。将鼠标悬停在某一行上，它会显示文件的提交注释，然后是更改集。找到可能的那一行，双击它，现在你就能看到更改集了。我们是一家很小的公司，从未有过 25 人的规模，但我们支持大量的用户。这种调试方式是我们能支持这么多人的重要原因。C）提交注释是按变更集而不是按文件写的。我们有一个图形化的签入工具，可以让你浏览文件列表，显示该文件的差异，并让你发表评论。现在，当你看到 ChangeSet 文件时，它会要求你提供 Git 所要求的注释，但差异是所有文件名，后面跟着你刚才写的内容。这让人们不得不提高提交注释的级别。我们的一些大客户坚持要求工程师使用该工具，而不是使用命令行来检查所有带有相同注释的内容。
– 子模块把 Git 变成了 CVS。也许现在已经重做了，但我上次看的时候，如果你有子模块，你就不能做横向拉取。BK 的做法更接近于正确，如果所有模块都存在，版本库产生的结果与单版本库完全相同（在稀疏的情况下，不填充模块的结果也完全相同）。无论是单版本库还是多版本库，语义和功能都完全相同。
– 性能。在大型版本库中，Git 的速度会变得非常慢，我们在 BitKeeper 中为此做了大量工作，在注释等方面，我们的速度快了好几个数量级。
总之，Git 并不是一个真正的版本控制系统，Linus 早在几年前就向我承认了这一点。版本控制系统需要忠实记录所有发生的事情，不多也不少。Git 不记录重命名，它通过值而不是引用在分支间传递内容。在我看来，这是一种巨大的倒退。
还有一件事。我们做了一个与 Git 兼容的 bk 快速导出和 bk 快速导入。你可以在 BK 中建立一棵树，并不断更新它，而且无论你在历史中的哪个位置运行 bk fast-export，都会得到相同的版本库。我们的快速导出是幂等的。Git 做不到这一点，它不会发送重命名信息，因为它不会记录重命名信息。这意味着我们必须在进行 bk 快速导入时编译重命名信息，也就是说 Git -> BK 并不是等价的。
我不指望在这一点上说服任何人，有人点拨，我就试一试。我已经不看 hackernews 了，所以不要指望我为自己说过的话辩护，我现在真的不在乎。我更乐于远离技术，我只是去海边钓鱼，不去想这些事情。
> 不支持重命名，只能猜测
Git 追踪的不是改动，而是状态。它有工具来比较这些状态，但这并不意味着它需要跟踪额外的数据来帮助这些工具。
我不认为跟踪重命名真的有用，因为这只是许多可能的状态修改中最简单的一种。如果你把文件 A 分割成文件 B 和 C 呢？你也需要能够跟踪这一点。把一个文件合并到另一个文件也是一样。还有很多很多可能的修改。因此，把重点放在状态上，然后改进比较它们的工具，才是明智之举。
跟踪所有类型的修改还需要所有开发工具都了解版本控制。你不能再使用标准工具进行大规模重命名，而是要以某种方式将它们构建在 vcs 上，这样它就能跟踪这些操作。这是跟踪版本库状态所不具备的巨大优势。
> 子模块
我同意，子模块和子树都不是理想的解决方案。
> 如果把文件 A 分割成文件 B 和 C 呢？你也需要能够跟踪它。把一个文件合并到另一个文件中也是一样。还有很多很多可能的修改。
我想，Bitkeeper 可以有意义地处理这个问题，因为他们的数据模型可以深入到文件内容。
> 在该文件上运行 bk revtool，找到断言并查看断言之前的更改。将鼠标悬停在某一行上，它会显示文件的提交注释，然后是更改集。找到可能的那一行，双击它，现在你就能看到更改集了。
我对 bk revool 仍记忆犹新。自那以后，我再也没发现任何东西能像它一样直观、实用。
你的回答非常详细。我还记得微软的 Windows [0] 在迁移到 git 时遇到了很多麻烦
0. https://arstechnica.com/information-technology/2017/05/90-of…
我还没听说过每个文件图的概念，我知道这很有用。但我不得不同意，钓一条鱼听起来很不错。
什么是 GCA？
最大共同祖先（git 术语中的合并基础）：
https://www.bitkeeper.org/man/gca.html
https://git-scm.com/docs/git-merge-base
作为一个在过去十年中一直使用 Git 的人，我也不明白为什么 Git 是一个糟糕的设计。它易于发布，运行良好，使用 tarball 服务器也没什么不好。
没错。虽然这篇文章很好地介绍了事件的历史，但对功能的演进（这与软件开发的演进密切相关，也反映了软件开发的演进）却不够深入。这就是……：
TeamWare – 易于分支（通过从父版本复制整个工作区，并将更改带入/放回，良好的合并工具），历史是本地的，部分提交。
BitKeeper 增加了分布式模式和变更集。
Git 增加了非常简单的分支、储藏等功能。
目前可用的其他源代码控制通常至少缺少其中一项功能。很能说明问题的是 Mercurial，它也是为了满足当时对现代源代码控制的同样需求而在差不多同一时间出现的，但却缺少了部分提交等功能，而且分支功能也非常繁琐（比如没有本地历史记录之类的–我上次看它还是十多年前的事）–这使得它只能在非常严格/苛刻的环境下使用，而对其他人来说，它是个不入流的东西。
Git 在分支方面做得很糟糕，不断地压制和重定向不是它的功能，而是一种烦恼。请参阅 fossil 了解如何进行适当的分支/合并/日志记录，这是它的本质。
>不断压扁和重定标不是一个功能，而是一种烦恼
例如，它是一个允许同时处理多个版本、补丁、热修复等的功能。一旦出现了更好的替代方案，我们就会像以前跳上 Git 这艘船时一样，跳上 Git 这艘船。
>将版本库与数据分开
这是很多源代码控制软件的特点，也是他们败给 Git 的原因之一。
>它迫使你
这也是源码控制输给 Git 的另一个原因，因为 Git 并没有强迫你以某种狭隘的方式做事。
当然，我不否认对于某些人/团队/项目来说，其他源代码控制方式会更好用，你的评论就说明了这一点。我只是想说为什么 git 能在大多数情况下胜出。
> 一旦出现了更好的替代方案，我们就会像以前跳上 Git 这艘船一样，跳下 Git 这艘船。
目前还没那么容易。git 的势头很猛，尤其是与 GitHub 的结合。
任何学习软件开发的人都会了解 git 和 GitHub。
人们希望软件能在 GitHub 上发布。
在 git 取得成功的时候，还有一些更好的系统，比如 mercurial，现在我们有了 fossil，但与对它的普遍了解以及与每种工具（任何编辑器、任何 CI 系统、任何软件包管理器……）和流程的集成相比，git 的缺点实在是太微不足道了。
>git 的势头很猛，尤其是与 GitHub 的结合。
当年的 CVS 也是这样，包括公共仓库等。
>在 git 取得成功的时候，可以说还有更好的系统，比如 mercurial
我在上文特别提到 Mercurial，是因为它们都是在应对同样的挑战时同时出现的，而 Mercurial 恰好在设计上不如 Git。公司也都在抢着用它，比如我们当时的管理层就选择了它，但它是一个可以预见的大麻烦，几年后就被 git 取代了。
> CVS 当年也是这样，包括公共 repos 等。
其实不然。
CVS 有太多的缺陷（没有原子性、没有适当的分支、没有良好的离线工作等），而 Subversion 作为 “自然的继承者”，修正了一些问题，并吞噬了 CVS 的某些部分。
与此同时，当时的 GitHub sourceforge 也开始疏远用户。
之后，企业在更大程度上使用了不同的工具（VSS、sccs、Bk、perforce 等），而现在这个市场基本上已经不存在了，Git 无处不在。
很多人没有版本控制的时间比现在要长得多。现在的孩子们很早就学会了 Git 的基本原理，甚至在 Windows 上也是如此，并将其作为一种习惯。而在 2000 年代初，我看到许多 “专业 “开发人员的版本控制只有”.bak “或”.old “文件或源代码目录的副本。
1986 年，人们开始付钱让我开发软件。我第一次使用版本控制软件是在 1996 年。它糟透了。两年后，我离开公司，创办了自己的软件公司，但在那之前，我使用版本控制软件的经验太糟糕了，所以前几年我都没有使用版本控制软件。2002 年左右，我开始使用 CVS（还是 RCS，很久以前的事了！），很快又换成了 Subversion。2009 年左右，我在 Raku 的工作中学习了 git，大概在 2012 年，我把我的 $WORK 主 repo 换成了 git。从那时起，我创建的每个 repo 都使用了 git，但我还没把所有的 svn repo 都转移到 git。
> 虽然现在这个市场基本上已经不存在了，而 git 已经无处不在。
在游戏开发领域，Perforce 依然拥有大批忠实拥趸–即使有了 LFS，git 对二进制文件的处理也只能算是差强人意。
是的，但市场份额已大幅缩水（尤其是在市场大规模增长之后），甚至连 Perforce 如今都成了与 git 集成的工具。
> 这是一项功能，可以同时处理多个版本、补丁、热修复等。一旦出现更好的替代方案，我们就会像以前跳上 Git 这艘船一样，跳上 Git 这艘船。
你在说什么？我不是在说取消分支，而是在说合并分支通常只是一次虚假的单次提交，掩盖了分支的复杂性和决定性。请参阅 [0] 了解如何利用分支和日志获得合理的提交历史。
> 这也是很多源代码控制软件的一个特点，也是它们输给 Git 的原因之一。
如果你有证据证明很多人都在说：”我讨厌数据和版本库的划分！”那么这个说法就可信了，或者你把数据/版本库的划分和 cvs 混淆了？
[0]: https://fossil-scm.org/home/timeline
> 特里奇做了以下工作。
> 这是一个 BitKeeper 地址，bk://thunk.org:5000。让我们试试用 telnet 连接。”
著名的是，特里奇就此发表了一次演讲，并让演讲听众重现了 “逆向工程”。资料来源见 https://lwn.net/Articles/133016/。
> 我今天参加了特里奇的演讲。演示中最精彩的部分是，他要求听众输入他应该输入的每一条命令。听众们立刻齐声喊出了每条命令（”telnet”、”help”、”echo clone | nc”）。
我参加了那次演讲，那是一段美好时光。多年来，Tridge 在 Linux.conf.au 上发表了很多精彩的演讲。
我也一样。我肯定还记得那句 “帮助”。
这完全不符合事实。你不可能通过 telnet 到 BK 并运行命令来克隆 BK。这些命令不会告诉你网络协议，只会告诉你该协议的结果，但对协议的深入了解是零。
特里奇没有告诉人们，当莱纳斯在他家做客时，他正在窥探莱纳斯运行 BK 命令时的网络情况。他就是这样完成克隆的。
事实上，你们都相信特里奇的话，这让人很失望，你们应该做得更好。
特里奇撒谎的事实令人失望，但我已经知道，只要能达到目的，开源人士愿意无视道德。我喜欢开源，但不喜欢道德。不只是特里奇。
> 你不可能通过 telnet 到 BK 并运行命令来克隆 BK。这些命令不会告诉你网络协议
根据多个消息来源和在 LCA 上的演讲，网络协议是 “向 URL 中可见的端口发送文本，得到文本返回”。收到的数据是 SCCS，这是现有工具可以理解的格式。而特里奇编写的工具 sourcepuller 并没有克隆 BitKeeper 的全部内容，它只克隆了足够的内容来获取源代码，这意味着 “连接、发送命令、获取 SCCS”。
除此之外都是道听途说，与已证实的证据完全不符。你有任何参考资料可以证明协议比他在 LCA 舞台上演示的更复杂，或者证明特里奇实施了你所说的网络监控？
再说清楚一点，除此之外，对专有工具进行更广泛的逆向工程以编写兼容的开源等价物绝对没有任何不道德之处。(如果像你所说的那样，他还在未经朋友明确知晓和同意的情况下记录了他们的网络流量，那就有问题了，但同样，这样做的必要性似乎与许多来源的证据完全不符。如果真的发生了这种情况，仅凭这一点我就会略感失望，但仍会感谢他对世界所做的净贡献）。
我很理解你当时对特里奇的工作感到愤怒，也许现在仍然如此，但这并不意味着它是错的。我们这些不使用专有软件的人很欣赏可用功能的净增长，就像我们很欣赏使用 Samba 与 SMB 进行互操作的能力一样，不管这对微软来说有多么不方便。
> 你试过了吗？
你回复的 @luckydude 是 Larry McVoy，他创建了 BitKeeper。
太有意思了，我还不知道有这个链接（而且在回复之前也没有系统地查看过别人的 HN 简介）。谢谢你的参考；我已经修改了我的评论，将其考虑在内。
我在 bk 工作过
> 收到的数据是 SCCS 格式，这是现有工具可以理解的格式。
你会很惊讶的。SCCS 并不广为人知。BK 也不完全是 SCCS。
我在 SourcePuller 代码发布（sp-01）时读过它。读起来很轻松。这要归功于 Tridge。我写了一个小测试，让它检出了错误的数据，而且没有错误报告。问题在 sp-02 中仍然存在。
如果说这里有什么不道德的地方，那就是把别人的数据锁在专有工具里，然后不让他们导出成开放格式。
拜托，老兄，你应该做得更好。这么多年过去了，你肯定已经意识到逆向工程并不是什么道德缺失。逆向工程带来了多少知识和文化财富？通过谷歌诉甲骨文一案，我们终于在法律上解决了外部可见的应用程序接口和实现行为不被视为知识产权的问题。
特里奇逆向设计了 bk，并引发了一系列导致 git 诞生的事件，这可能是有史以来对软件行业产生最积极影响的事情之一。无论在当时还是今天，他都不应该因此受到抨击。我很感激他，我们都应该感激他。我知道这对你来说很刺痛，但我希望有一天你能在事后总结经验，并以积极的态度看待这段历史–因为即使事情没有按照你希望的方式发展，你自己对这段历史的影响最终也是非常积极和有意义的，你应该以此为荣，而不是贬低他人。
这个帖子是胡说八道。你应该删除它。
有一张截图自称是 2008 年 5 月的 GitHub。但有迹象表明，部分或全部 CSS 已无法加载，而且如果你当时访问该网站的话，这并不是网站真正的样子。事实上，如果你在 Wayback Machine 中查看 github.com，就会发现其最早的抓取时间是 2008 年 5 月，但却未能捕获外部样式表，因此当你今天尝试加载该副本时，会出现 404。遇到这种情况，最好还是不要截图。
(虽然在这种情况下这样做特别愚蠢，因为在 Wayback Machine 中访问该副本[1]会发现，GitHub 网站包含的自身截图与本文中的截图完全不同）。
1.<https://web.archive.org/web/20080514210148/http://github.com…>
作者在此。很好，谢谢！我用 2008 年 8 月的最新截图替换了它。
拉里想给你打电话，讨论对这篇文章的两处修改（”一处小修改，一处大修改”）。为了方便起见，我已经把你的电子邮件地址传给了他，但你还是应该联系他。
我已经给他发邮件跟进了。谢谢你告诉我！
谢谢–我很难相信 GitHub 会以如此糟糕的面貌上线–2008 年的网页可不是欧洲核子研究中心（CERN）时代的网页！
有趣的是，这篇报道引用了 Larry McVoy 本人在 HN 上发表的评论（未注明出处！）。
https://news.ycombinator.com/item?id=11671777
这部分真的应该直接引用；对原帖进行了非常轻率的改写，感觉形式很糟糕。
这篇文章的整个评论区都是一座金矿，谢谢！
> 在 Stack Overflow 2022 年的一项调查中，Git 的市场份额为 94%，…
> 历史上从来没有一个版本控制系统能像 Git 一样主导市场。下一个取代 Git 的会是什么？很多人说可能与人工智能有关，但谁也说不准。
我很怀疑它会被取代。这不仅是因为它占据了如此大的市场，还因为市场比 CVS 时代大得多。
很难想象每个人都会从 Git 转向 Git。从 GitHub 转向 Git？从 Git？那就难多了。
在这一点上，Git 的缺点已经众所周知，所以后继项目要做的 “只是 “解决这些问题。Git 可以扩展到 Linux 内核规模的项目，但事实证明还有更大、更复杂的项目，所以它无法扩展到 Google 规模的组织。你会希望支持集中式和分散式操作，但同时也要意识到这两种操作，因此它可以支持多个远程操作，同时也更容易保持它们的一致性。Github 上的副本是否与 gitlab、CI 系统、我的笔记本电脑和台式机同步？它必须能很好地处理二进制文件，而且是原生的，这样我就能签入我的 100 兆字节的 jpeg 文件，而不会把事情搞得一团糟。你既想把它用作单发布仓库，也想把它用作多发布仓库，因为它允许你只签出单发布仓库的子树。在本地，工作流程既要支持 git 的复杂性，又要比 git 更容易使用。
总之，在我看来，要取代 git，必须做到以上四点。
如果有了这样一个系统，让人们不再使用 git 就不是问题了–提供 git 兼容性，如果他们不想使用高级功能，就可以继续使用现有的 git 工作流程。但这样做的问题是，为什么还要使用你的新系统呢？
这就涉及到一个问题：如何让它成为一个全球性的全球产品？FAANG 规模的公司都有自己的内部工具团队来管理源代码。任何规模较小的公司都没有预算从零开始创建这样的产品，但
你不能去做这个产品，然后把它卖给别人，因为有多少公司会选择一个未经验证的新工作流程工具，而他们的工程师又想要这个工具呢？对于那些认为 “git 还不够好”，而且腰包足够鼓的公司来说，TAM 又是什么呢？
你说得没错。GIT 不是 DVFS，而是 DVCS。它是用来跟踪源代码的，而不是二进制数据。如果你把二进制数据放到 DVCS，那你就做错了。
但是，有些行业需要它，比如游戏行业。因此，他们应该使用允许这样做的工具。我听说 Plastic-SCM 在这方面做得很好。但我从未使用过，所以无法亲身体验。
取代 GIT 是个愚蠢的想法。没有一种工具能处理所有情况。只需根据自己的工作流程使用合适的工具即可。例如，我需要对二进制文件进行版本控制。我知道 GIT 处理得很糟糕，但我真的很喜欢这个工具。解决方案是什么？我为这种情况编写了自己的简单 DVFS 工具：dot.exe (138KB)
这是一个非常简单的 DVFS，供个人使用，点对点同步（本地、TCP、SSH）。数据和元数据都经过 SHA-1 校验。它的速度非常快，能满足我的需求:)经过几周的使用，我非常喜欢它，因此添加了包存储来处理文本文件，并将我的所有笔记从 SVN 移到 DOT 🙂
DVCS 代表分布式版本控制系统，它与源代码有什么关系？
也许你把它和 SCM 弄混了，SCM 是源代码控制管理器，是唯一只处理严格源代码的管理器，但 scm 也有其他含义。
很难说。对我来说，DVCS 是 DVFS 的高级版本。DVCS 可以做分支和合并，为修订提供更多的元数据等。而 DVFS 只做了一件事，那就是存储二进制 Blob。由于二进制 Blob 无法轻松合并，我不会用它来存储。但我想，这只是我的想法。）
如果你想存储大的二进制文件，不是有 git-annex [0] 吗？
[0] https://git-annex.branchable.com/
我知道 git-annex。它可能是大数据的好解决方案。就我而言，我并不想将存储与元数据解耦。我想要的是自成一体的单一项目的单一 repo。这样更易于管理，因为它是真正的分布式存储。无需费心备份，因为每个副本都已经拥有所有内容。对于几 GB 的数据来说，这是个不错的模式。
我也是这么想的，对我来说，GIT 是文本文件版本管理的最佳选择。
不处理二进制文件对我来说不是缺点，因为 GIT 不应该是处理二进制文件版本管理的工具，我们应该用其他工具来处理。
当你有一个很小的 .png 或 .jpg 文件需要与源代码共存时，你会怎么做？
我可以把二进制文件放到 GIT 仓库中，尤其是小文件和不会改变的文件–人们想要的是 “很好地处理二进制文件”，不管这意味着什么，但把大的二进制文件放到 GIT 中，或把大量二进制文件放到 GIT 中，或对它们进行版本控制，这都不是 GIT 的用例。
把它放到你的 Git 仓库中就可以了。
你是这么说的，但 Git 近年来在扩展巨大仓库方面取得了长足进步。目前你可以很好地做到 “只签出单仓库的子树”，还可以使用浅克隆来接近集中式系统（最重要的是减少了本地存储的使用）。
> 如果有了这样一个系统，让人们离开 git 就不是问题了–提供与 git 的兼容性和[…]
Git 已经在这么做了。
> “检出的只是 monorepo 的子树”
如何签出（例如 https://github.com/neovim/neovim/tree/master/scripts）一个目录，并把它当作一个 repo 来处理？
不行（因为提交是版本库根目录的快照）。不过，你可以使用这种近似方法：
git clone --filter=blob:none --sparse https://github.com/neovim/neovim cd neovim git sparse-checkout add scripts不幸的是，GitHub 不支持 –filter=sparse:oid=master:scripts，所以 blob 会在你使用 repo 时按需获取。
但 Git 本身并非如此，它没有任何实际意义。要克隆 mono repo 中的所有子树，这在可用性上是不可能的。你需要一个知道如何在访问时提取文件的伪文件系统。而且最好能与构建系统集成，以抵消按需进行远程操作的成本，并提高并行性。Facebook 正在开源他们的许多工作，但都是基于 mercurial。微软已经买入了 git，但目前还没有开源其支持 git 的工具，因此这一点并不可行。
总之：问题更为复杂，假装 “你可以检出一个子树 “就能解决问题，其实是舍本逐末。
微软的 git vfs 是开源的。scalar 也是。这是微软用于大型仓库的两种主要方法。不幸的是，技术上更胜一筹的 vfs 方法在 macOS 上并不成功。
感觉就像在问：”什么将取代 ASCII？”扩展当然可以，但 0x41 在公元 5050 年将表示 “A”。
作者在此。我不认为 ASCII 是正确的比较。的确，任何东西都很难与 Git 竞争，因为我们拥有的很多基础设施都已与 Git 深度集成。但想想 x86 与 ARM 的对比，以及人工智能会如何改变我们的代码生成方式。
UTF-8
不过这也验证了 gp 的观点：UTF-8 并没有取代 ASCII，而是对其进行了扩展。所有有效的 ASCII 文本仍然是有效的 UTF-8，同时保持相同的含义。以 git 的发展势头，不兼容的东西很难取代它，但扩展的 git 可能会流行起来。
我真的很怀疑这会发生。当它达到谷歌规模的 repos 时，就会失败。但无论如何，世界上大多数人都不会使用这么大的版本库。
只有那些庞大的组织才会使用替代品，而且通常都是他们自己做的。对其他人来说，git 已经足够好了。
好久没读完这么长的文章了。写得非常好！
我试图找出作者是谁，或者他/她为什么知道这么多。没找到。还有谁知道或者 OP 愿意提供一些信息？
Here: https://news.ycombinator.com/item?id=40849363#40854063
精彩阅读
我相信我不是第一个指出 Junio（指定的 git “牧羊人”）在谷歌工作的人，在谷歌内部，mercurial 是 “推荐的本地 vcs”，而不是 git。
谷歌的很多部门都依赖 Git，其中最著名的是 Chrome 浏览器和安卓系统。
此外，如果朱尼奥能在不影响谷歌当务之急的情况下独立完成工作，也是一件好事。
顺便提一下，Mercurial 的开发者现在的名字是 Olivia Mackall；遗憾的是，谷歌的信息框没有显示更新的信息。
已更新，谢谢。
这个故事缺少了汤姆-洛德的 TLA 对 git 设计的影响。
前情提要<https://news.ycombinator.com/item?id=32155067#32157109>
> 没有腿的被严重镇静的树懒可能更快
从现在起，我要借用这句话来形容一切缓慢的事物。
这句话真的把我带回了过去。在 Git 还没大红大紫的时候（2010/2011 年左右），我不幸在一家使用 IBM Rational ClearCase 的大型企业工作，感觉糟透了。不过，由于它太糟糕、太昂贵，我被委以 “修复它 “的重任。为了解决这个问题，我从瑞典来到了 2011 年的 GitTogether。很多当年的 Git 朋友都来了，至少我记得 Junio、Peff 和 Shawn Pearce 都来了。我当时非常兴奋，回去后组建了一个小团队，在接下来的两年里把一个庞大的代码库（我有很多恐怖的故事）迁移到了 Git 上。这是我职业生涯早期做的最有意义的一件事。
感谢你们创造了 Git、Gerrit 以及这个行业所缺少的所有救命工具，让这一切成为可能！肖恩-皮尔斯（Shawn Pearce）的逝世令人惋惜，但我们不会忘记他！
> 此外，Petr 还为 Git 创建了第一个项目主页 git.or.cz，以及代码托管服务 repo.or.cz。在 GitHub 接管之前，这些网站一直是 Git 的 “官方 “网站。
这是真的吗？我还以为 GitHub 与 Git 项目没有官方关系呢
我认为有些 Github 员工写的代码被放到了 git 中，但这并不是正式的隶属关系。
在我看来，”官方 “的引号意味着非官方，即在不了解情况的人看来是官方的。
git repo 位于 kernel.org，镜像位于 repo.or.cz 和 GitHub。
但我认为他们指的是包含文档等内容的 git 项目官方 “网站”。该网站现在是 https://git-scm.com/，而且正如文章所述，它最初是由 GitHub 的人建立的，目的是推广 git
这就是为什么 “官方 “要加引号。就像”事实上的标准”。
git-scm.org 是 Git 项目事实上的 “官方 “网站，就像法语是法国事实上的 “官方 “语言一样。
他们的意思和他们写的完全一样：GitHub 接管了 Git 官方网站的托管职责（因为他们确实接管了）。
有趣的阅读
bitkeeper 的授权是真实存在的。虽然我现在完全不关注内核邮件列表了，但我记得艾伦-考克斯（Alan Cox）把它称为 buttkeeper。美好时光
我以前听说过这个故事，但读起来还是很有趣。我没有意识到最初版本的 git 是如此简陋。这让人不禁要问：git 是建立一个无处不在的版本控制系统的最后机会吗？还会有下一次机会吗？不管 git 的技术优点如何，有一点我非常高兴，那就是它是免费软件。它似乎是在自由软件雪崩之前出现的，真正改变了人们的工作方式（希望是好的）。
早期的 Git 有两个关键功能，它们显示了 Git 对 Linux 内核开发的支持：
https://git-scm.com/docs/git-am
https://git-scm.com/docs/git-send-email
Git 是为支持 Linux 内核邮件列表而建立的。虽然在同一时期也出现了许多其他选择，但其中许多并不能满足当时对 Git 的核心需求–减轻 Linus 的压力/工作量。
它造成了雪崩。如果没有 git 和 GitHub，我想我们现在拥有的自由软件规模是不可能实现的。
我以前从未听说过 “瓷器 “这个词，但我喜欢这个小故事。
“在软件开发术语中，将底层基础架构比作管道是很难追溯的，但使用 “瓷器 “来描述高层封装则起源于 Git 邮件列表。时至今日，Git 仍用 “plumbing “和 “chorcelain “分别指代低级和高级命令。”
另外，与此无关的是，”Ruby 人，奇怪的人 “视频让我捧腹大笑。
https://www.youtube.com/watch?v=0m4hlWx7oRk&t=1080s
为了继续工作而向源代码控制工具供应商申请许可简直是无稽之谈。
今天它还活着！Sr.ht 也有不能托管的工作类别。还在酝酿中。
因为有了 rails，我们只能用 git，真是诗情画意。
关于许可
> 如果您正在使用版本控制软件，就不能使用 BitKeeper 进行版本控制。
> 如果您想在运行 BitKeeper 的同时运行其他类似软件，您必须获得 BitMover 的许可。
这简直不可理喻。
我没有使用 c 语言的经验，我想知道：为什么莱纳斯决定使用脚本语言而不是 c 语言来实现合并？
> bk clone/pull/push 命令的功能与 git clone/pull/push 类似。
这听起来有点倒退：实际上，Git 的工作方式与 BitKeeper 类似（由于我对 bk 不熟悉，所以不能说在多大程度上类似），而不是相反。
这就是我来 HN 的原因。感谢作者。
天哪，这真是一本好书。
> 2006 年 1 月，X Window 团队从 CVS 转向 Git，这让朱尼奥大吃一惊。他没想到像 X Window 这样的大项目也会大费周章地更换版本控制系统。
这就是 “X Window System”，简称 “X”。