Gitの先へ——ERSCが挑む次世代バージョン管理
What Comes After Git
Steve Klabnik氏がEast River Source Controlの構想を語る。エージェント開発の普及でリポジトリは肥大化し、Gitは2005年の制約に縛られている。ERSCはGitプロトコルを話しながら独自のストレージエンジンで水平スケールを実現し、将来はJujutsuの複数バックエンド方式をサーバー側で再現する。
はっきり言えば、Gitがソース管理の未来だとは私たちは考えていない。Gitは長年開発者に貢献してきたが、2005年の制約を前提に設計されており、2025年はおろか2035年には合わない。
HNでの議論
31- nrr
ここでも他のコメントと同じことを言わせてもらうよ。この記事は、ERSCが将来的にGitをどう作り変えるつもりなのか（移行パスとしてのJujutsu以外に）、あるいはなぜ（我々が知る）Gitの居場所が将来ないのかについて、本当に詳細が乏しい[0]。
たまたまこの問題について技術的な背景[1]があるんだけど、この発表にはかなりがっかりしたよ。せめてpack-protocolのワイヤーフォーマットがどれだけ厄介かくらい言及してくれよ！技術者でGitの内部事情にどっぷり浸かっている我々に、一緒に愚痴をこぼすネタを提供してくれよ！
とはいえ、Fossilに言及があったのは良かった！ \o/
--
0: そう、彼らはエージェント的な開発パターンと、モノレポ指向のパターンがぶつかる制約について言及しているけど、詳細は手を振って流している。特にエージェント的な開発パターンの何がGitに負荷をかけるのか？エージェントを使っていない、あるいはほとんど触れたことがない我々には、これは特に自明ではない。しかしその利用パターンは、小規模な開発現場が遭遇するGitの他の使われ方にもほぼ確実に反映されているはずだ。
1: 私は、Gitのオブジェクトストアをむしろ追記専用ログのようなものに作り変えることに自分で挑戦できないか、長い時間をかけて検討したことさえある。それは、例えばヘビーなGitOpsワークフローが時に引き起こす問題のいくつかを軽減するためであり、ましてやエージェント開発をめぐる熱狂を考えればなおさらだ。つまり、この領域は誰かがもっとうまくやってくれるのを待っている。しかしバージョン管理は技術者のための技術的ツールなのだ。
- rbsmith
これは記事というより、ここにある多くのコメントへの返答であり、彼らがどんな価値をもたらすのかという視点を提供するものだ。
私はバージョン管理／SCMの世界で35年以上を過ごしてきて、その半分はBitKeeperチームの一員だった。そこでの私の仕事は、セット、グラフ、ウィーブについて、商用顧客の生活をより良くしつつオープンソースの世界にも利益をもたらすチームという文脈で考えることだった。
もしGitがあなたにとって十分なら、それが誰にとっても真実ではないと知っておいてほしい。その「誰も」の一部にとっては、その痛みを取り除くためにお金を払う価値がある。そして痛みを取り除くことの一部は、現状の世界のスーパーセットであり続け、非互換な形で優れているのではない形で、すべてとつながり続けられることだ。私がSteveとチームが描く絵に見るのはそれだ。つまり、痛みを取り除くためにお金を払う気のある一部にとってより良い形でGitと対話する世界だ。
Non-Git Storage Engineについてはあまり語られていないことに同意する。私も人生の半分をその世界で過ごしてきたのでわかる。秘伝のタレだ。しばらくは多くが語られることは期待していない。
- EddieRingle
他のコメントと同様、これがGitの競合を自称するものと、またしても超特定的な「カンファレンス」を宣伝する以外に何を意図しているのか、非常に混乱している。この投稿は、議論をすべきセクションでさえ、実際には何の議論もしていない。そしてなぜか、GraphQLまで混ぜ込んでいる。どういうことだ？
- asmnzxklopqw
彼らは何の問題を解決しようとしているのか？この部分はまだ私にはよくわからない。
- fergie
私にとって、Gitが素晴らしいとは言えない実際の点はデータ（ベース）のバージョン管理だが、この記事はそれに対処しているようには見えない。実際、記事が提案する問題／解決策を解析するのに苦労している。