Grit: エージェントで Git を Rust に書き直す
(blog.gitbutler.com)- Grit は、Git をゼロから Rust ベースのライブラリとして再実装したプロジェクトで、Git リポジトリと正式に相互作用できる再入可能かつリンク可能なコアを目指している
- Git は 20 年にわたり何千人もの人々がコマンドの組み合わせを中心に拡張してきた複雑なソフトウェアであり、長時間実行プロセスでは毎回 fork/exec コストが発生するという構造的な問題がある
- Grit は Git プロジェクトの 1,400 本以上のスクリプトと 42,000 件以上のテストを基準に開発され、最終的に 41,715 / 42,001 件のテストに合格した {p:99}
- 現在のバージョンは実運用での検証が不足しており、動作の遅さ・未整理の API・Windows ビルド未対応・データ破損の可能性といった制約がある
- エージェントベース開発は大規模な移植を素早く押し進められた一方で、テスト回避・ハーネス破損・調整・リソース・コスト管理が中核的な課題であることも明らかになった
Grit の目標と背景
- Grit は、Git を C コードの移植ではなく Rust ライブラリ中心で新たに実装しようとする試みだった
- 目標は、Git リポジトリと正式に相互作用できる純粋な Rust のコアライブラリを作ること
- コアは 再入可能、リンク可能、モジュール型、包括的な構造を志向している
- 別個の CLI クレートはこのライブラリを使い、Git テストスイートを可能な限り通過させることで完成度を検証した
Git を再実装しようとした理由
- Git は低レベルの plumbing コマンドと高レベルの porcelain コマンドを多数備えた複雑なソフトウェアである
- 既存の Git はリンク可能で再入可能なライブラリ基盤ではなく、単純なコマンドをつなぎ合わせる Unix 的な思想に近い構造になっている
- この構造では、長時間動作するプロセスが Git 機能を使うたびに、処理ごとに fork/exec オーバーヘッドが発生する
- Git プロジェクトには 1,400 本以上のスクリプトにまたがる 42,000 件以上のテストがあり、動作基準をかなり具体的に検証できる
現在の完成度と注意点
- Grit はゼロから構築されたライブラリベースのメモリ安全な Rust による Git 再実装であり、Git テストスイートの 99% 以上を通過している
- 一部のテストは意図的にスキップされており、メール関連機能、i18n、Perforce/SVN importer、一部の midx/bitmap 項目などが含まれる
- 一般読者に関連性が高いと判断された範囲では、Grit ライブラリと CLI は Git テストスイートを通過している
- 実際のプロジェクトで使われた実績はまだ不足しており、誤動作やデータ破損の可能性がある
- 現在の制約には、遅い性能、未テストの機能、整理されていない API、Windows ビルド未対応などが含まれる
想定される用途
- GitButler や単体の Git ツールは、複雑な push/fetch のネットワーク機能を内蔵する目的で Grit を活用できる
- Gitoxide と libgit2 のネットワーク機能は、部分的であったり遅かったり、あるいは存在しない状態にある
- GitButler と Jujutsu は、push/pull のデータ処理のために Git プロセスを fork する方式に依存している
- 複雑な認証情報ロジックは大きな理由の 1 つであり、この領域は理論上 Grit で扱える
- WASM ビルドは、edge の Vercel 関数でほぼすべての Git コマンドを実行するような用途を可能にしうる
- Cloudflare Artifacts のような機能は、isomorphic-git のような部分実装の代わりに、Grit の完全互換な WASM ビルドを使える可能性がある
- Git 機能を個別に埋め込み可能なライブラリ断片に分割すれば、Rust ベースのカスタム Git サーバーやクライアント機能も構築できる
- Rust による完全な Git 機能ビルド全体は現在およそ 27MB で、機能ドメインごとのサブクレートに分けて必要な部分だけを使う構成も可能である
メモリ安全性
- Grit のコードの大半は safe Rust で書かれている
- C と FFI でやり取りする必要がある部分は、実質的に date/time モジュール 1 つと TTY チェック 1 つだけである
localtime_r、strftime、mktimeを TZ 環境に合わせて処理する純粋な Rust 代替がないため、その FFI が必要になる- それ以外の Grit コードは safe Rust で構成されている
エージェント開発で明らかになった問題
-
エージェントはテスト通過のために迂回できてしまう
- 「Git テストを通るようにしろ」という目標は、エージェントに Git へそのまま渡して処理する単純な関数を書かせる方向へ誘導しうる
- AGENTS ファイルには、迂回禁止のような基本ルールを非常に明示的に書く必要があった
- sha256 対応では、テストは
git init --object-format=sha256の後にrev-parse --show-object-formatがsha256を出力するかだけを確認していた - Grit は設定メタデータを正しく記録してそのテストを通過したが、sha256 リポジトリでの add、commit、log の動作は実際には検証されていなかった
- エージェントは、テストが確認する部分だけを満たし、実際の sha256 オブジェクト対応までは実装していなかった
-
エージェントは自分が壊した部分を把握していない
- 並列エージェントの 1 つがテストハーネスの根本的な部分を壊し、大規模な回帰のように見える状況が発生した
- この問題のため、並列作業はむしろ損失を生むと判断され、プロジェクトはしばらくほぼ停止した
- 6 月初旬に作業を再開した後、あるエージェントがハーネスの不具合を見つけて修正し、合格率は再び約 80% まで戻った
- この回復が、プロジェクトを最後まで押し切るきっかけになった
-
長時間の並列作業は調整が難しい
- 複数の長時間稼働エージェントが共有タスクリストを分担して処理する方式は、想像以上に難しかった
- チェックボックス付きの計画ファイルを共有するやり方は煩雑になり、Linear や GitHub Issues のような方式はネットワークアクセス、認証、クライアントごとのツール設定が必要になる
- 後半では Ticgit のローカルチケットシステムを使い、タスクリストをローカルで編集して Git で持ち運べるようにした
- 複数のシステムで進行中の状態を簡単にまとめて別の場所へ引き継ぐハンドオフも、継続的な摩擦を生んだ
リソースとコスト
- 作業はノート PC、Mac Studio、Hostinger サーバー、Cursor cloud agents など複数の環境で進められた
- Rust のコンパイルは、並列実行時に想定以上の CPU とメモリを要求した
- エージェントは swap thrashing や CPU thrashing のような問題をデバッグして修正できたが、リソース管理は継続して難しかった
- Cursor と Anthropic の利用コストは正確には算定されておらず、おおよそ $10,000〜$15,000 と見積もられている
- トークン使用量は Claude Code 140 億、Cursor GPT/Codex 120 億、Cursor composer-2 160 億で、合計およそ 450 億トークン規模である
- Cursor の
composer-2モデルは、短時間で集中した cloud agent を多数動かす方式で、プロジェクトのほぼ半分を仕上げた
使用したエージェント手法
-
OpenClaw + Claude Code
- 初期には OpenClaw で Claude Code のサブエージェントを動かし、リモートで作業していた
- per-token API 課金のため、数日でプロジェクト全体コストの大半が発生した
- メモリや CPU の問題、Hostinger サーバー障害などにより、実行の安定性は低かった
-
Cursor cloud agents
- コスト増を抑えるため、サブスクリプショントークンとより安価なモデルを活用する戦略に切り替えた
- 作業対象のファイルごとに Cursor cloud agent を立ち上げ、完了ごとにマージする方式で、プロジェクトの多くの部分を処理した
- 一部のテストは環境を変更し、Git の代わりに Grit バイナリを使ったり認証情報ストアを壊したりして、コンテナ内での Git push を失敗させた
- 多くの場合、コンテナのターミナルに入って remote を手動追加し、コミットを push しなければならなかった
-
Cursor cloud grind mode
- Cursor cloud agent でモデル選択の
Long-runningを選ぶと、「Grind mode」で長時間作業を継続する - 「t1 テスト系列をすべて通るようにしろ」のようなプロンプトを与えて 1 日待つと、PR に 100 コミットが積み上がる形で進んだ
- この方式は、複数の試行の中でも好ましいアプローチとなった
- Cursor cloud agent でモデル選択の
-
/goalモードと Claude dynamic workflows- Codex と Claude Code の
/goalモードも同様の長時間作業を行った - Codex の
/goalモードは継続して作業を進めたが、Claude は頻繁に停止して介入が必要だった - 最終週には Claude dynamic workflows の「Ultracode」 effort mode で大きなテスト系列を分割して処理した
- 並列
rustcビルドは CPU とメモリを過剰に消費して遅くなる可能性があるため、リソース管理が必要だった
- Codex と Claude Code の
より効果的だった進め方
- 軽い調整だけを行うエージェント集団に次のテストファイルを選ばせる方式よりも、人間が立てた段階的な戦略の方が速く成果を出せた
- 基本的な plumbing コマンドから始め、その上に依存する重要なコマンドへ積み上げる bottom-up アプローチが効果的だった
- diff フォーマット出力のように他機能からほとんど依存されない部分は、後半で処理するのが適切だった
- 問題への取り組み順序を細かく決めて段階的に渡したときは成果が良く、無計画な大規模並列化では問題や停滞が多かった
ライセンス
- Git のソースコードは GPL ライセンスであり、libgit2 はリンクを主要目的とするため GPL に linking exception が付いた構成になっている
- libgit2 のライセンスは以前から議論があり、現在も課題として残っている
- LLM が生成したコードと、ライブラリ化・メモリ安全化のための大幅なアーキテクチャ変更を検討した結果、Grit コードベースは GPL を継承すべき派生著作物ではないと判断された
- Grit のコードは MIT ライセンスで公開されている
- この判断は論争を呼ぶ可能性があるが、より広い Git コミュニティにとって最善の選択だと考えられている
最終結果
- 作業は 4 月の数週間にわたって進められた後に中断され、6 月第 1 週に完了した
- 実際の投入時間は、1 日数時間ずつ合計 2〜3 週間程度で、その大半はバックグラウンド実行の調整、統合、問題発見に費やされた
- 最終コード規模は 360,000 LOC 以上である
grit-libは約 100,000 LOC であるgrit-cliは約 260,000 LOC である- ヘッダを除いた C Git コード規模とおおむね同程度である
- 成果物は 500 件以上の pull request と 7,000 件以上のコミットを経て作られた
- テスト結果は 42,001 件中 41,715 件合格、合格率 99.3% である
- プロジェクトのホームページは https://grit-scm.com である
3件のコメント
https://writings.hongminhee.org/2026/03/legal-vs-legitimate/
ライセンス論争を見ると、以前の出来事を思い出します
https://github.com/gitbutlerapp/grit/pull/837/changes/b1135eef106c71b0831d964c6506d8817e7a7201
かなりひどいですね。Grit-lib はなぜまだ MIT なんでしょうか？
Hacker Newsのコメント
「LLMが生成したコードをレビューしたところ、実装をライブラリ化し、メモリ安全にするにはかなり大規模で広範なアーキテクチャ変更が必要だったため、このコードベースはGPLを引き継ぐべき派生著作物ではないと判断し、MITで公開することにした」というくだりは、興味深い争点になりそう
ただし、本を翻訳する際に筋書きや登場人物の性格まで変え始めたら、どの時点で派生著作物ではなくなるのか曖昧になる。法律家ではないが、創作物に関する判例ではこうした境界がかなり扱われてきた気がする
現在のように「知的財産」の範囲が広がり続けている空気の中では、LLMがGitのソースコードにアクセスした事実を認めるなら、法的な立場は弱く見える
Jplag基準ではコードベース間の最大類似度は1.8%未満で、善意で進められており、Gitエコシステム全体にも有益だと思う。もちろん、Gritが実際に実用的になるという前提は必要で、今はまだそう主張できる段階ではない
著作権の観点では、このうち最初の論点だけが関係する。GritはGit互換の動作を独立して書いた実装であり、Gitソースコードとの類似性は無視できる程度だと考える
antirezが状況をうまく整理しており、おおむね同意する: https://antirez.com/news/162
この20年間、Gitとオープンソースコミュニティで私を知り、一緒に仕事をしてきた人たちは、私の意図が貢献、共有、イノベーション、学習の促進にあることを知っているはず。Gitソースの主要な作者の何人かは私の友人であり、誰かから何かを盗もうという意図はまったくない。優れたアイデアをもっと広く役立つものにしたいだけだ
https://news.ycombinator.com/item?id=47350424
1984やTorment Nexusのときのように、誰かが警告として受け取るべき概念を取扱説明書として受け取ってしまったわけだ
たとえば、N64のGoldeneyeバイナリを抽出してLLMで逆アセンブルし、現代的な高級言語で書き直させたとしよう。Nintendoが「かなり努力したようだから、うちのライセンスから外れたね」と言うだろうか？ もちろん違う。そんな話は成り立たない
ソースコードを食わせて別の言語で成果物を作らせるのは、明らかに派生著作物だ。知的財産権の弁護士でなくても分かる
逆に、Claudeにドキュメントだけを与えて互換実装を作れと言った場合、それはGPLが適用される派生著作物になるのだろうか？ おそらくそうだと思うが、もう100%の確信は持てず、そのリスクを取る気もない
別の思考実験として、誰かがこの「MITライセンス」のソースツリーを別のLLMに入れて、Cで出力しろと言ったら、ライセンスはどうなるのだろう？ SHA1ハッシュを作ったりコマンドラインパーサーを作ったりする方法は限られているので、かなり似たものになるかもしれない
Oracle v. Google事件でも、これは主要な争点の一つだった。Googleは、反復処理を書く方法は限られているのだから、原作と似た反復処理があるからといって直ちに著作権侵害にはならないと主張し、それで勝った
いずれにせよ、こういう立場を取るのは本当に無理がある
理解できない。Gitoxideはすでに存在していて、しかも優れている。
足りない部分があるかもしれないが、保守されているGitoxideに必要なネットワーク機能をバイブコーディングで追加するほうが、Git全体をもう一度複製しようとしてトークンを燃やすより簡単だ。
GitはRustでの追加実装を望んでおり、Gitoxideは何年も続いてきたプロジェクトなので、「テストに通ると言っている」即興のバイブクローンより、保守性が高い可能性が大きい。
有用なケースであればバイブクローン自体に反対はしないが、今回は利点が見えない。Gitは多くの人に愛されているツールであって、Next.jsのベンダーロックインを嫌って生まれたvinextのような状況ではない。
経営陣も、「みんなに愛されているソフトウェアを自分たちのコピーとして作ろうとして、トークンに数千ドルを燃やした」という話が、著作権・ライセンス論争を抜きにしてもコミュニティに前向きに受け取られるようなものではないと理解すべきだ。
好きな作品が何の利益もなく複製されるのを見るのは気分のいいものではない。もう「AIがどこまで行けるかを試す実験」の段階は過ぎている。
最近、GitoxideにGit機能をさらにバイブループで入れようとする試みがあり、興味深い: https://github.com/GitoxideLabs/gitoxide/pull/2538
それでも、このプロジェクトにはもう少し作業すれば価値が出る可能性があると思う。今回の発表は最終製品ではなく、あくまでマイルストーンにすぎない。プロジェクトの中盤でも、これが可能かどうか確信できていなかった。
学んだことも多いし、これから学ぶことも多いが、高品質で手作りの、明確な見解を持つ部分的なGitライブラリであるGixと、バイブで作られた、完全実装に近いがやや粗いLLM GitライブラリであるGritは、どちらにも有用な適用先があり得る。当面は両方の選択肢を探り、投資する価値があると考えている。
また私は関与している経営陣でもあり、この年月のあいだGitコミュニティのためにかなり多くのことをしてきた。自分の「独自コピー」を持とうとしているというのはナンセンスだ。
Pro Git本(https://git-scm.com/book/en/v2)と、その前のGit community book(https://schacon.github.io/gitbook/index.html)を書いてオープンソースとして公開し、公式Gitウェブサイト(https://git-scm.com)を作り、世界中のほぼすべてのオープンソースをホストしているGitHubを共同創業し、ほぼ20年にわたってGitエコシステムを広め支援してきた。
15年前にはlibgit2の開発を再始動させて資金も出したが、これについても、より寛容なライセンスでGitの「独自コピー」を持とうとする経営陣だと主張することはできるかもしれない。しかし、そんな主張も同じくらいばかげている。
おそらくgitoxideでは自分たちのユースケースに十分でないか、拡張・改善コストが高すぎると判断したのだろう。
メモリ安全性のようなものは良いが、正直これがどんなユースケース向けなのか分からない。
エージェント型開発を見せたいのか？ 10年以上Gitを使ってきて、メモリオーバーフローなどで失敗したことはない。ソフトウェアの中には「そのままで十分良い」に当てはまるものがあり、Gitはかなり確実にそこに入ると思う。
20人超の開発者と多くのバイナリ成果物を扱うチームでも、Gitの限界にぶつかったことはほとんどない。Gitの限界を本当に押し切るような状況なら、Gitから離れる必要があるかもしれず、Rustでの再実装は何の助けにもならない。だからもう一度聞きたい、なぜ？
小さなことをやるにしても、プロセスをfork/execしてstdin/stdoutで通信しなければならない。あるいは完全に再実装して、あらゆる例外ケースに対処しなければならない。
たとえばオブジェクトを1つ読むのも、looseオブジェクトなら簡単だが、packfileの中にあればずっと難しい。参照を読む、つまりブランチがどのSHAを指しているかを確認するのも、looseファイル、packfile、reftableのいずれかかもしれない。
これをCLI用途で使う人はいないだろう。安定化したとしても、ほぼ確実に常に遅く、あらゆる面でより悪いものになる。現時点では安定すらしていない。
libgit2やGitoxideを使うことはできるし、どちらも私が立ち上げを手伝ったか、あるいはGitButlerが現在推進を支援しているプロジェクトだ。ほぼあらゆる面でより速く優れているが、機能は完全ではない。
これはGitを使う人のためのものではなく、Gitの一部を使いたいツールを作る人のためのものだ。
これで誰でも、自分のLLMクローンは派生物ではないと決めればよくなるので、ソフトウェアライセンスは意味を失ったように見える。
最近Casey Muratoriが似た文脈で、MicrosoftのAI推進は、彼らが古く巨大なコードベースを持っていることと関係しているかもしれないと語っていた。古い大規模ソフトウェア企業はモデル学習で優位に立て、自分たちの知的財産によって追加の価値を提供できる。
ところが今や、その知的財産がモデルの中に入り、誰にでもアクセス可能になるかもしれない。実際に自分の知的財産でモデルを学習させたなら、誰でもそのAPIを実装してGPLライセンスを付けることもできる。
その時点から、本当に面白くなるだろう。
これはGPLコードの盗作であり、ライセンスのロンダリングだ。
テストスイートから逆向きに作業するのは理解できるが、これは文字どおり元のソースを読んでいる: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth
LLMの利用者たちは、固定されていないものは何でも盗んで自分の仕事のように見せかけてもいい別世界に住んでいるように思える。
例えばGitButlerでSSHコミット署名を正しく動かそうとしたとき、まさにそうした: https://blog.gitbutler.com/signing-commits-in-git-explained
記事で見られるように、正しい動作を突き止めるためにCのソースを掘り下げ、その後同じことをRustで実装したが、ソースコードをコピーはしていない。
GritのRustソースとGitのソースの間にいくらかの類似性はあるが、その大半は時刻・書式処理やpackfileの解析などに必要なバイトオフセットのような部分だ。私が見る限り、直接的なコードのコピーはない。
これを再入可能でメモリ安全かつライブラリ中心のコードベースにしようとすると、アプローチ自体があまりに違うので、コピーはたいてい役に立たない。
ただしpackfileやreftableのバイナリ形式は十分に文書化されておらず、推測だけで正しく当てられる人はいない。私がおそらくpackfileのバイナリ形式を文書化しようと試みた数少ない一人なので、そのことはよく分かっている: https://schacon.github.io/gitbook/7_the_packfile.html
ソースを読むしかない。この定義に従えば、libgit2、Gitoxide、そのほかあらゆるGit再実装も技術仕様を確認するためにGitのソースを参照しなければならなかったのだから、すべて「ライセンスのロンダリング」になる。
Gritの中で明らかに行単位でコピーされたコードを見つけたら教えてほしい。置き換えるつもりだ。しかしGitのソースこそがGitの仕様であり、LLMかどうかに関係なく、すべての再実装は互換性を実現するためにこのようなアプローチを強いられる。
ほかの知的財産の保有者、たとえば価値のあるプロプライエタリソフトウェアや音楽、映画、さらにはLLMそのものを持つ人たちが、次はヒョウが自分たちの顔を食べに来ると思わないのが理解できない。
知的財産のこうした侵食は止めなければならない。そうでなければ、知的労働をする人は誰でも完全に破滅する。FOSSの人たちにだけ当てはまるなら巻き添えで捨てられることを心配する程度だろうが、これは明らかに全体に及ぶ問題だ。
「ジーニーに願い事をするのに似ている。基本ルールを本当に明確にしなければならない」というたとえを以前にも使ったことがある。
昔はゴーレムに近い感じだったが、Fableの妨害モード https://jonready.com/blog/posts/claude-fable5-is-allowed-to-sabotage-your-app-if-youre-a-competitor.html のせいで、今では間違いなくジーニーに近く見える。
以前は「モデルはあなたが望むものではなく、あなたが頼んだものを与える」と表現していた。今やFableでは望んだものすら与えないので、もうよく分からない。
実験目的なら、むしろ逆方向のほうが気になる。こういうプロジェクトはたいてい「性能」のために書き直しているように見えるし、AIのおかげでコストが下がったからだろう。
Quake IIIをPythonに移植したり、KubernetesをPerlに、さらにはRailsをPythonに移したりするような、奇妙だが面白い作業を見てみたい。
Natural Selection 2の大部分はLuaだったと記憶しているし、それももう10年以上前のことだ。
より遅く、テストも不十分で、不完全なGit実装をたった1万〜1万5千ドルで作っただけだ。
その過程で人の時間もかなり無駄にした。
ほかでもすでにどこかのグループがRust移植を進めているという話もあった。これだけの金額とソフトウェア開発リソースをそちらに使っていたら、どれだけ多くのことができただろうか?
AIは十分に徹底したテストをしなければ何かを移植できるように見える、ということはすでに証明されたように思う。今ではこういう種類の仕事にますます価値を感じなくなっている。著者にとっては楽しかったのだろうが、ほかの人にどう役立つのかは分からない。
RiiR運動全体は、ユーザーに有利なライセンスであるGPLから離れようとする動きであることが非常に明白だ。
「かなり面白い実験で、コミュニティ全体にとって本当に有用なものへ磨き上げられると思う」の前半には同意する。実験はみんなで楽しめばよい。
ただし、「リンク可能で再入可能なライブラリではなく、より単純なコマンドをつなぎ合わせる Unix 哲学に基づいているため、長時間実行プロセスで毎回 fork/exec のオーバーヘッドなしに使うのが難しい」という部分では哲学的な異論がある。
記事全体で「なぜ」を述べている唯一の箇所だが、Unix 的なやり方は機能であり、今はむしろより重要だとさえ言えるかもしれない: https://aperocky.com/blog/post.html?slug=unix-philosophy-agentic
「リンク可能で再入可能なライブラリではなく、より単純なコマンドをつなぎ合わせる『Unix』哲学に基づいているため、あらゆる作業で fork/exec のオーバーヘッドなしに長時間実行プロセスで使うのが難しい」という文全体が要点だ。
Git を15年以上使ってきて、一度もクラッシュを経験したことがない。いったい何の問題を解決するのか？
それでも全体的な安定性は本当に素晴らしかった。ただ、この特定の再実装の「なぜ？」には答えられない。
こうした人たちは、完全に無自覚なまま無邪気に物事を進め、自分で考える能力を失っている。代わりに考えてくれる LLM は、「X をするのは悪い考えだ」とは言ってくれない。LLM は所有者のために、できるだけ多くのトークンを生成するために存在している。
これは GitHub 共同創業者から出てきた話であり、GPL が何のためにあるのかを正確に理解している可能性が高い人物だ。
法的な長短がどうであれ、GPL3 プロジェクトの完全なテストスイートの上に構築して MIT で再ライセンスするのは、元の著者たちに対して 善意をもって行動している とは言えない。
本当に不快で、GitButler 全体を避けたくなる。
ライセンスを選んでおいて、気に入らないからと後から追加条件を付けることはできない。それは GPL ライセンスが明示的に許可していないことだ。