【Show HN】AIエージェントに特化したGit代替ツール「Oak」が爆誕！高速開発の未来を切り拓く

Oakは、AIエージェントの作業に最適化された新しいバージョン管理システムです（https://oak.space ）。本格的なプロジェクトにおいて、エージェントが必要とするコンテキストを即座に提供し、開発スピードを劇的に向上させます。仮想マウント機能により、ローカルやクラウド上のエージェントがリポジトリ全体のコピーを持つ必要はありません。巨大なリポジトリをダウンロードしたり、複雑なワークツリーの管理に悩まされたりすることなく、複数のタスクを並行して進めることが可能です。バージョン管理は、あなたやAIエージェントの時間を奪うものではなく、創造的で楽しい体験であるべきだと考えています。現在Oakは開発初期段階であり、Windows版への対応やCI、Issue、コメント機能などは未実装です。ビルドにはGitHub Actionsを使用していますが、Oakの開発自体は数ヶ月前からGitに頼らず、完全にOak自身のブートストラップで行っています（https://oak.space/oak/oak ）。ブログ記事（https://oak.space/blog#git-is-forever ）やドキュメント（https://oak.space/docs ）もぜひチェックしてみてください。

EmacsやVim、Neovimのundo-tree0みたいな機能が、永続的かつソーシャルになったバージョン管理システムをずっと欲しがってたんだ。なんでわざわざ手動でgitと対話しないといけないんだろう？PCなんだから、編集中のすべての変更を追跡して、どこでチェックポイントを作るかを（あるいはその決定を助けてくれるように）させてほしいよ。

git上でエージェントを動かすための独自のワークフローを構築したよ。最近は複数のリポジトリを跨いで作業したり、同じリポジトリで別のタスクを同時にこなしたりすることが多いからね。worktreesを使う手もあるけど、いっそのこと逆にしたいと思ったんだ。エージェントにワークスペースを持たせて、そこにリポジトリをpullさせて、好きなようにブランチを作ったり、mainにコミットさせたりしてもいいようにする。これならエージェント同士が邪魔し合うこともないし、いざマージする時も、コンフリクトが解消されていればスムーズに進むからね。

このツールはgitnowって言うんだけど、正直かなりシンプルだよ。プロジェクトを作って、必要なリポジトリを追加してビルドするだけ。Claudeとかのチャットツールでこのツールを操作させて、Zellij（Zedやtmuxでもいいけど）と組み合わせるとかなり上手くいくよ。

それと、エージェントが至る所にメモリファイルをばら撒く問題もこれで解決できる。エージェント専用のスクラッチスペースができたから、そこにタスクを保持しつつ、必要な時にリポジトリを更新できるようになったんだ。

これを使うなら、evalした後にシェルでgnを使うといいよ。サブシェルを作らずに直接cdを実行してくれるから。

https://github.com/kjuulh/gitnow (https://github.com/kjuulh/gitnow)

それって、gitの上に構築するんじゃなくて、別物として作るようにエージェントから促されたりしたの？

エージェントにとってgit（や他のVCS）よりも優れている点が、一体どこにあるのかさっぱり分からないな。

パフォーマンスの話が少し出てるけど、確かにそれは素晴らしい。でも、gitのパフォーマンスってエージェントにとってボトルネックになってるか？

トークン使用量が減るっていう話も、それ自体はいいことだけど、gitのporcelainモードと比べてどうやってそれを実現したんだ？なぜトークンを減らすために全く新しいVCSが必要で、既存の確立されたgitエコシステムとの非互換性を受け入れなきゃいけないんだ？

気に入る理由を探したいんだけど、今まで見た中で最悪レベルのプロダクトマーケティングだよ。これほど大きな変更なら、開発チーム全員にgitから乗り換えようと納得させるために、もっと強力なメリットを提示する必要があるはずだ。

Zachは自分の功績を控えめに言ってるな。彼は以前、有名な創業者が買収したJamhub VCSを構築した実績があるんだ。

レイジーマウント（遅延マウント）はかなり興味深いね。Googleのgoogle3がやっていることと似てるけど、オープンソースで同じような実装は今まで見たことがなかった。

Gitのsparse checkoutも便利だけど、必要な時にファイルを取り出すやり方の方がずっと柔軟で直感的だと思う。

MicrosoftのVFS for Git / GVFSが一番近い考え方かな。

このレイジーマウントのアイデアをgitの上に構築する余地は十分にあるはずだよ。

この分野で似たようなことをやっている競合に追いつくには、スタートアップ形式で資金調達する必要があると思う（恐らくそうするつもりだろうけど）。

この問題領域とソリューションはビッグテックでは随分前から存在していて、今では一般に知られた製品がいくつかあり、秘密裏に開発されているものも数十個はあるだろう。AIやエージェントの利用が増えた今、狭い範囲に特化したVCSのビューを簡単に扱えるソリューションが必要とされているんだ。

ファイルシステムのマウント（通常はFUSE-FS）で、データを大量転送せずに複数のビューアからバージョン管理システムを見る手法については、以下のような実装が過去にもあったよ。

• Google: Piper via CitC (Clients in the Cloud)。Cider（Web IDE）でよく使われていたね
• Meta: Sapling on EdenFS (働いたことはないけど、聞いた話だとそうらしい)
• Rational Clearcase。VOBsをマウントしてたのを覚えてる人はいるかな？

一番の問題は、サイトがAI生成っぽいテキストの塊で、何が起きているのか理解しづらいことだね。ベンチマークコードから辿れるGitHub UIのクローンという面白い部分すら、しっかりアピールできていない。

余談だけど、4方向の矢印ロゴも既に誰かが使っていたはず。検索してみたけど、以前参加した英系IT企業の研修で、マルチカラーの似たロゴを見た記憶があるよ。

すごく興味深いけど、今のところパフォーマンス以外にgitから乗り換えるメリットが見えにくいかな。誤解しないでほしいんだけど、パフォーマンスが良いのは素晴らしいことだ。でも、みんながgitを捨ててoakに移るほどの強力な動機付けにはなっていない気がする。

まだ初期段階だし、私がgitに対してずっと「こうあってほしい」と願っているけど実現されていないことをいくつか挙げてみるよ。これに対応すれば、同じような悩みを持つユーザーが増えて、大きなユーザーベースを獲得できるかもしれない。

• プライベート/パブリックの境界をレポジトリ単位ではなく、もっと流動的なものにしてほしい。パブリックレポジトリの中に、プライベートなサブディレクトリやファイルを持てるべきだ。そうすれば、大きなプロジェクトでも「機能の一部だけ」をオープンソース化できる。今はall-or-nothingだから、それが多くの巨大なクローズドプロジェクトの足かせになっている。
• 環境変数。oak内で環境変数の扱いをもっとシームレスにできれば、多くの人が納得すると思う（私も含めて）。今のgitと環境変数の管理は本当に頭痛の種で、本来こうあるべきではないはずだ。
• PR以外のエージェント同士のコラボレーション。具体的にどうあるべきかは分からないけど、gitの「PR作成・マージ」というサイクルは本質的にエージェント向きではない気がする。

素晴らしい取り組みだと思う。頑張って！

「エージェント向け」と謳うものは何であれ、モデルのトレーニングデータに既に組み込まれている既存のツールよりも優れているという証拠が必要だ。「ある側面で使いやすい」だけじゃダメなんだ。モデルは古いツールの「難しい部分」を既に学習済みだし、一度学習したものを忘れて新しいことを学ぶことはできないから、新しいツールを使うことには常にコンテキストコストがかかる。

モデルは膨大なトレーニングデータを通じてgitを熟知している。でも、新しい「エージェント向け」ツールのことは何も知らない。だから、スキルやドキュメントを通じてその使い方を教え込まないといけない。もちろんドキュメントを読み込ませればモデルは使えるようになるだろうけど、結局のところ、何十年も前から人間に使われてきた既存の強力なツールよりも、この新しいツールは出遅れた状態でスタートすることになるんだ。

新しいものを作ること自体はいいんだよ（以前似たような指摘をした時に、新しいことを否定するなと怒られたことがあるからね）。ただ、私が「エージェント向け」という言葉を見ると「本当にそうか？」と疑いたくなる。エージェントはgitを使う上で特に困っていないから、何か私の知らない「エージェントとgitを併用する際の苦痛」があって、それが解決されているのか、あるいは単に誰かが作りたかっただけのプロジェクトなのか。もし後者なら、「エージェント向け」という言葉はただのマーケティングで、それなら興味はないな。

でも、スピードは設計の結果であって、売り込みの理由じゃない。

うーん、そこがよく分からないな。著者がたった数段落の説明文を書くことすら面倒くさがっているような中心技術を、私が使えってことか？