几个月前，我读到了 Anthropic 的实验，释放一群代理去编写一个功能齐全的 C 编译器，这让我思考用同样的方式实现我梦想了 15 年的事情的可行性，那是在我们成立 GitHub 不久后 - 从头开始重写 Git，使其基于库。Git 当然是一个非常复杂的软件。它有很多 "管道" 命令，还有许多更高级的命令 - 它是过去 20 年来成千上万的人为大型和小型项目逐步拼凑而成的。它从未基于可链接和可重入的库，而是基于 "Unix" 的哲学，通过循环组合更简单的命令，这意味着在不使用 fork/exec 开销的情况下，很难在长时间运行的进程中使用它。然而，有趣的是，在 Git 项目中有一个非常全面的测试套件，包含超过 42,000 个测试和超过 1,400 个脚本，清晰地定义了一切应该如何运作，应该如何不运作。如果我们采用 Anthropic 在他们的从零开始的 C 编译器中使用的基本想法呢？启动一个全新的实现，将其设计为一个 Rust 库，然后对着这个问题投入一群代理，不断努力直到所有测试通过？好吧，我在过去几个月间随意进行了一些尝试，结果是 Grit，这是一种从头开始开发的、基于库的、内存安全的、符合习惯的 Rust 实现 Git，它通过了整个 Git 测试套件的 99% 以上。新的 Grit 项目网站。注意！虽然 Grit 通过了测试，但它未经过测试。没有人用这个做过任何实际的事情。如果你玩这个，要注意目前有很高的概率它会做错事，甚至可能破坏一些东西。使用风险自负。但是如果你发现了问题，请告诉我们，以便我们修复。与 Anthropic 的实验不同，这并不仅仅是看是否可以实现。当我们开始时，我想如果这能工作，我们可能会在 C Git 有问题的方面得到一些真正有用的东西。但我们稍后再讨论这个。我想从中得到什么？我不想要一个纯粹的 C Git 在 Rust 中的移植。事实上，越是深入，我甚至不确定我是否应该复制 Git 中曾做出的每个决定，但在实现原始目标之后这是我们可以继续努力的事情。我想要的是一个纯 Rust 的核心库，它能够与 Git 仓库忠实地交互，具有可重入性、可链接性、模块化和全面性。然后，为了确保其全面性，我们实现了一个独立的 crate，提供一个 CLI 接口，使用该库以通过尽可能多的 Git 测试套件。这就是我们所做的。实际上，不是的，但这确实很有意思，且可以说已经有用。首先，一些警告。它并没有通过每一个测试，尽管这是故意的。我确实标记了一些测试套件的部分为 "跳过"，因为我认为在这样的库中重建它们没有必要 - 电子邮件相关的内容、国际化、perforce/svn 导入器、中间索引/位图等 - 这类东西。然而，就我确定对阅读本文几乎每个人都相关的所有内容而言，Grit 库/CLI现在可以完全通过 Git 测试套件。这是否意味着它是完美的？不。它仍然相当慢（在某些情况下呈指数级），有一些未经过测试的事情它无法完成，API 也不是特别干净，没有 Windows 构建，等等。这是第一次尝试的第一个里程碑。然而，对几个月的工作和几十亿个 token 来说，这是一个相当有趣的起点。我们可以用这个做什么？这是一个有趣的项目，但我们这样做并不仅仅是为了看看是否可以做到。我认为 Grit 可以轻松地发展成一些非常有用的东西。我希望能用它实现的主要功能之一是能够将复杂的推/拉功能捆绑到 GitButler 和其他需要网络功能的独立 Git 工具中（例如 Jujutsu）。目前，Gitoxide 和 libgit2 的网络功能要么部分实现，要么缓慢，要么不存在。GitButler 和 Jujutsu 都依赖于从 Git 中分叉以推送或拉取数据。造成这种情况的一个重要原因是涉及的凭据逻辑极其复杂，但所有这些（理论上）目前都在 Grit 中得到覆盖。另一个可能的用例是可以用于做各种有趣事情的 WASM 构建。例如，几乎可以在边缘 Vercel 函数中运行任何 Git 命令。或者，也许你可以构建像 Cloudflare Artifacts 这样的东西，而不依赖于像 isomorphic-git 这样的部分实现，而是依赖于 Grit 的完全合规的 WASM 构建。将 Git 的部分作为离散的、可嵌入的库切片，也使得用 Rust 构建自定义 Git 服务器或客户端功能成为可能。在已知版本中将整个 Git（或仅所需的 Git）本地嵌入到诸如代理桌面构建或 Zed 编辑器之类的东西中。完整构建所有 Git