Кому нужная новая VCS, когда уже есть Git, Mercurial, SVN, Perforce, Darcs и прочие? Автор проекта Jujutsu считает, что ещё есть куда совершенствоваться. Знакомьтесь — Martin von Zweigbergk из Google работает над проектом Jujutsu, или для краткости jj.
Плюсы:
Невероятно гибкая работа с коммитами и ветвлением. Основное отличие jj от Git cостоит в том, что история коммитов представляет из себя последовательность патчей, а не snapshot-ов. Идея взята из Darcs. Такой подход позволяет легко переписывать историю коммитов, rebase становится тривиальным, коммиты (патчи) можно спокойно перемещать между ветками, конфликтов меньше (автоматическое разрешение конфликтов работает лучше, чем в Git или Mercurial).
Например, у вас есть история коммитов, но один коммит «Create file A» не должен быть в истории. Подход jj состоит в том, что все коммиты после «плохого» нужно переместить (rebase) на «Initial commit». Для этого нужно поменять ссылку на родителя командой jj rebase -s yyltlwtl --destination krpsnnrr.
Если в качестве родительского коммита указать не один, а 2 и более, то jj смержит эти ветки. Случайно смержили не ту ветку? Ничего страшного. Сделайте rebase, указав только одного родителя, тем самым отменив слияние веток.
Можете переключится на старый коммит, поменять файлы, изменить комментарий, а затем вернуться к самому свежему коммиту. Изменения в истории автоматически подтянутся.
Отмена любого действия. Все изменения в репозитории можно откатить. Есть как простой jj undo так и полная история ваших действий над репозиторием jj op log.
Поддерживает чтение и запись в Git remote. Можете попробовать импортировать свой pet-project и поиграться с коммитами
Написан на Rust. Это заметно по скорости работы и простоте установки: скачиваете один бинарник и прописываете его в PATH. Правда из-за этого возникает проблема с GIT+SSH. Об этом ниже.
Консоле-ориентированность. Утилита jj делает работу в консоли приятной. История коммитов выглядит красиво. jj diff удобно подсвечивает изменения файлов прямо в консоли.
Минусы:
Отсутсвие аналога git stage. Все изменения в файлах рабочей копии автоматически коммитятся. Нельзя закоммитить часть локальных изменений, оставив другие изменения висеть в рабочей копии. Авторы jj рекомендуют создать отдельную private ветку, запретив её заливать на сервер. Все локальные изменения нужно делать в private ветке, сливая её с последним коммитом, и отменяя merge перед отправкой на сервер.
Непонятно, какой flow использовать. Можно продолжать использовать git flow. Но думаю стоит изобрести новые более гибкие правила для работы с ветками, фичами и релизами в jj.
Нет поддержки private key авторизации через SSH. Jujutsu не используется OpenSSH, установленный в системе. Вместо этого jj слинкован с libgit2. Поэтому он игнорирует ~/.ssh/config. По этому поводу есть issue в Github.
Нет поддержки git submodules. Но у разработчиков есть план, как их добавить.
Jujutsu ещё не добрался до версии 1.0, но уже смог удивить своими идеями и подходом к VCS. Определённо стоит попробовать, хотябы для личного пользования. Основная проблема jj такая же как у Mercurial, Bazaar и прочих — они не Git. Многие уже подсели на Github/Gitlab и не могут легко переключиться на jj. Инструменты и инфраструктура вокруг Git делают его стандартом для индустрии.
Комментарии (21)
kresh
30.10.2024 15:55А на Habr писали уже про post-git VCS типа Pijul и Fossil SCM? Как я понял Jujutsu тоже основана на Patch theory но нигде ещё не видел сравнения этих трех VCS.
funny_falcon
30.10.2024 15:55Fossil - это не post-git. Да, это коробочное решение «все-в-одном»: wiki, issue tracker и, собственно, SCM. Да, есть какие-то улучшения благодаря использованию SQLite в качестве стораджа. Но концепция SCM там всё-же очень близка к Git: цепочки снапшотов.
Особенно не приятно, что в Fossil нет ребейзов веток. Ричард Хипп говорит, что в компании (разрабатывающей SQLite3) ребейзы объявлены вредными, и потому в Fossil они не реализованы. Это удерживает меня от экспериментов с Fossil, т.к. на примере некоторых old-school открытых проектов я вижу пользу линейной истории главной ветки.
seyko2
30.10.2024 15:55А в чём эта польза выражается? (не спец, особо пока git не пользовался, в основном копил последовательность патчей, то есть обычные патчи: снизу вверх, а не сверху вниз как вроде бы хранит git.
khajiit
30.10.2024 15:55В линейной истории проще разобраться, чем в многомерной макаронине, множество раз пересекающейся сама с собой.
nuclight
30.10.2024 15:55Натыкался на этот jj весной в поисках идей для своей DVCS. Увы, при том же гите как формате хранения ничего инновационного там архитектурно нет и быть не может - так, только CLI-удобства какие...
Основная проблема
jjтакая же как у Mercurial, Bazaar и прочих — они не Git. Многие уже подсели на Github/Gitlab и не могут легко переключиться наjj. Инструменты и инфраструктура вокруг Git делают его стандартом для индустрии.И это, собственно, ключевой момент, который не понимает автор статьи - использование чего-то в качестве "стандарта" не отменяет ни других средств, ни исследований в этой области, которые со временем победят, если сумеют предложить что-то действительно новее и лучше. Двадцать лет назад таким "стандартом" для приложений была Windows - всё, нету этого, теперь Web, облака и мобилы. Еще через 20 лет и это перестанет быть стандартом, и т.д.
Panzerschrek
30.10.2024 15:55Интересно, но не практично. git стал отраслевым стандартом, с ним все умеют работать, куча инструментов под него заточено. Лучшие (в теории) альтернативы просто не могут в таких условиях существовать.
feelamee
30.10.2024 15:55Многие уже подсели на Github/Gitlab и не могут легко переключиться на
jj. Инструменты и инфраструктура вокруг Git делают его стандартом для индустрии.Вы ведь сами сказали тут:
Поддерживает чтение и запись в Git remote. Можете попробовать импортировать свой pet-project и поиграться с коммитами
что jj может работать с git.
Поэтому это решает проблему зависимости от инфраструктуры git.
mayorovp
Вообще-то в гите история коммитов логически тоже представляет из себя последовательность патчей. Это только на уровне хранения они снапшоты.
iliazeus
Насколько понял из описания, суть
jjв том, что если у коммита поменять родителя - то это все еще будет тот же коммит. В отличие отgit, где это уже новый коммит с новым хешем.Поэтому обычно как раз-таки удобнее считать коммиты в git не патчами, а именно снепшотами. Один хеш - одно состояние кода.
Sap_ru
Но тогда получается Mercurial, который Git, но с хранением метаинформации и неизменным хэшем, со всеми вытекающими плюсами и минусами. И JJ превращается в велосипед.
funca
Что-то подобное было реализовано в Darcs. Но на больших репозиториях он еле шевелился, был весьма прожорливым по памяти и при слияниях часто получалась каша. Если в jj смогли решить проблемы, то это неплохой апгрейд для велосипеда.
questpc
При этом для git до сих пор нет полнофункционального бесплатного кроссплатформенного gui клиента, такого как TortoiseHG. Хотя о git знают все, он везде в требованиях а о Mercurial знают единицы.
Misteg
Любая современная IDE подойдет как GUI?
x4x7
В статье очень мало внимания уделено сути. Даже на скриншоте видно что у каждого коммита есть два хеша - один, который слева, не меняется при внесении изменений. Справа - обычный из гита, который меняется. Они имеют разный формат, например нулевой коммит это и zzz и 0000
sheknitrtch Автор
Я не стал в статье погружаться в детали реализации. Есть интересное видео с живыми примерами использования https://www.youtube.com/watch?v=2otjrTzRfVk. Есть отличная документация. Мне было важно пояснить, чем jj лучше или хуже Git.
ixSci
Всё с точностью до наоборот: логически git представляет собой граф снапшотов (деревьев), а вот реализация использует pack files.
mayorovp
pack files не имеют никакого отношения к последовательности патчей, это просто способ сжатия.
В отличии от патчей, на pack files никак не влияют ни настройки LF/CRLF, ни настройки отображения пробельных символов, ни настройки логического сравнения файлов.
ixSci
Ну я вроде обратного и не утверждал? Последовательность патчей это вообще не про git, а pack files я привёл только из-за упоминания патчей в Вашем комментарии. Т. к. они хранят дельту, они ближе всего к понятию патчей, но это всего лишь деталь реализации, связанная с оптимизацией. Можно легко представить git без оптимизации, где вообще дельты не хранятся ни в каком виде.