Git не будущее контроля версий, утверждает основатель East River Source Control
What Comes After Git
Steve Klabnik из East River Source Control считает, что Git устарел: он создавался под ограничения 2005 года и не рассчитан на агентную разработку, гигантские монорепозитории и облачные среды. Компания строит систему, которая говорит на протоколе Git, но использует собственный движок хранения. В будущем планируется поддержка Jujutsu (jj) через отдельный протокол, что позволит внедрять новые инструменты постепенно.
Говоря прямо, мы не верим, что Git — это будущее контроля версий. Git хорошо служил разработчикам много лет, но он проектировался под ограничения 2005 года, а не 2025, и тем более не 2035.
- nrr
Я присоединюсь к другим комментариям здесь: эта статья действительно очень скудна на детали о том, как ERSC намеревается переделать Git для будущего (помимо Jujutsu как пути миграции) или почему для Git (в том виде, как мы его знаем) нет места в будущем[0].
Мне довелось иметь технический контекст вокруг этой проблемы[1], и я был довольно разочарован анонсом. Хотя бы упомянули бы, насколько геморройным является проводной формат pack-protocol! Дайте нам, техническим людям, погружённым по уши в дела Git, что-то, над чем можно посочувствовать!
При всём этом, Fossil упомянут! \o/
--
0: Да, они упоминают агентные паттерны разработки и ограничения, с которыми сталкиваются паттерны, ориентированные на монорепозитории, но детали отмахиваются. Что именно в агентных паттернах разработки так напрягает Git? Для тех из нас, кто не использует агентов или имеет ограниченный опыт с ними, это не особенно очевидно, но паттерны использования почти наверняка отражаются в других применениях Git, с которыми сталкиваются небольшие компании.
1: Я даже долго и упорно рассматривал возможность самому попробовать переработать объектное хранилище Git, чтобы оно больше походило на append-only лог, с целью облегчить некоторые проблемы, которые, например, могут иногда вызывать интенсивные GitOps-воркфлоу, не говоря уже об ажиотаже вокруг агентной разработки. Мол, эта область созрела для того, чтобы кто-то пришёл и сделал это лучше, но контроль версий — это технический инструмент для технических людей.
- rbsmith
Это скорее ответ на многие комментарии здесь, чем на статью, предлагающий точку зрения о том, какую ценность они могут принести.
Я провёл около 35+ лет в сфере контроля версий / SCM и вокруг неё, половину этого времени будучи частью команды BitKeeper, где моей работой было думать о множествах, графах и weave в контексте команды, делающей жизнь коммерческих клиентов лучше вместе с пользой для мира открытого исходного кода.
Если Git достаточно хорош для вас, знайте, что это не так для всех. Для некоторого подмножества этих всех стоит заплатить, чтобы эта боль ушла. И частью того, чтобы эта боль ушла, является возможность оставаться связанным со всем, что есть, быть достаточно надмножеством текущего мира, чтобы не быть лучше несовместимым образом. Это то, что я вижу на картинках, которые рисуют Стив и команда: мир, который взаимодействует с Git так, что это лучше для некоторых, готовых заплатить, чтобы боль ушла.
Я согласен, что о Non-Git Storage Engine почти ничего не говорится. Поскольку я провёл половину своей жизни в том мире, я понимаю: секретный соус. Я не ожидаю, что многое будет сказано в течение некоторого времени.
- EddieRingle
Как и другие комментарии, я очень смущён тем, что это должно делать, кроме продвижения хочу-быть-конкурента Git и ещё одной гиперспецифичной "конференции". В посте на самом деле нет никаких аргументов, даже в разделе, который должен приводить аргумент. И почему-то они добавляют GraphQL в смесь, каким-то образом?
- asmnzxklopqw
Какую проблему они пытаются решить? Эта часть всё ещё не очень ясна для меня.
- fergie
Для меня настоящая вещь, для которой git не фантастичен, — это версионирование данных (баз данных), но эта статья, похоже, не рассматривает это. На самом деле я с трудом разбираю предложенную в статье проблему/решение.