Кому нужная новая 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)


  1. mayorovp
    30.10.2024 15:55

    Основное отличие jj от Git cостоит в том, что история коммитов представляет из себя последовательность патчей, а не snapshot-ов.

    Вообще-то в гите история коммитов логически тоже представляет из себя последовательность патчей. Это только на уровне хранения они снапшоты.


    1. iliazeus
      30.10.2024 15:55

      Насколько понял из описания, суть jj в том, что если у коммита поменять родителя - то это все еще будет тот же коммит. В отличие от git, где это уже новый коммит с новым хешем.

      Поэтому обычно как раз-таки удобнее считать коммиты в git не патчами, а именно снепшотами. Один хеш - одно состояние кода.


      1. Sap_ru
        30.10.2024 15:55

        Но тогда получается Mercurial, который Git, но с хранением метаинформации и неизменным хэшем, со всеми вытекающими плюсами и минусами. И JJ превращается в велосипед.


        1. funca
          30.10.2024 15:55

          Что-то подобное было реализовано в Darcs. Но на больших репозиториях он еле шевелился, был весьма прожорливым по памяти и при слияниях часто получалась каша. Если в jj смогли решить проблемы, то это неплохой апгрейд для велосипеда.


        1. questpc
          30.10.2024 15:55

          При этом для git до сих пор нет полнофункционального бесплатного кроссплатформенного gui клиента, такого как TortoiseHG. Хотя о git знают все, он везде в требованиях а о Mercurial знают единицы.


          1. Misteg
            30.10.2024 15:55

            Любая современная IDE подойдет как GUI?


      1. x4x7
        30.10.2024 15:55

        В статье очень мало внимания уделено сути. Даже на скриншоте видно что у каждого коммита есть два хеша - один, который слева, не меняется при внесении изменений. Справа - обычный из гита, который меняется. Они имеют разный формат, например нулевой коммит это и zzz и 0000


        1. sheknitrtch Автор
          30.10.2024 15:55

          Я не стал в статье погружаться в детали реализации. Есть интересное видео с живыми примерами использования https://www.youtube.com/watch?v=2otjrTzRfVk. Есть отличная документация. Мне было важно пояснить, чем jj лучше или хуже Git.


    1. ixSci
      30.10.2024 15:55

      Всё с точностью до наоборот: логически git представляет собой граф снапшотов (деревьев), а вот реализация использует pack files.


      1. mayorovp
        30.10.2024 15:55

        pack files не имеют никакого отношения к последовательности патчей, это просто способ сжатия.

        В отличии от патчей, на pack files никак не влияют ни настройки LF/CRLF, ни настройки отображения пробельных символов, ни настройки логического сравнения файлов.


        1. ixSci
          30.10.2024 15:55

          Ну я вроде обратного и не утверждал? Последовательность патчей это вообще не про git, а pack files я привёл только из-за упоминания патчей в Вашем комментарии. Т. к. они хранят дельту, они ближе всего к понятию патчей, но это всего лишь деталь реализации, связанная с оптимизацией. Можно легко представить git без оптимизации, где вообще дельты не хранятся ни в каком виде.


  1. kresh
    30.10.2024 15:55

    А на Habr писали уже про post-git VCS типа Pijul и Fossil SCM? Как я понял Jujutsu тоже основана на Patch theory но нигде ещё не видел сравнения этих трех VCS.



    1. funny_falcon
      30.10.2024 15:55

      Fossil - это не post-git. Да, это коробочное решение «все-в-одном»: wiki, issue tracker и, собственно, SCM. Да, есть какие-то улучшения благодаря использованию SQLite в качестве стораджа. Но концепция SCM там всё-же очень близка к Git: цепочки снапшотов.

      Особенно не приятно, что в Fossil нет ребейзов веток. Ричард Хипп говорит, что в компании (разрабатывающей SQLite3) ребейзы объявлены вредными, и потому в Fossil они не реализованы. Это удерживает меня от экспериментов с Fossil, т.к. на примере некоторых old-school открытых проектов я вижу пользу линейной истории главной ветки.


      1. seyko2
        30.10.2024 15:55

        А в чём эта польза выражается? (не спец, особо пока git не пользовался, в основном копил последовательность патчей, то есть обычные патчи: снизу вверх, а не сверху вниз как вроде бы хранит git.


        1. khajiit
          30.10.2024 15:55

          В линейной истории проще разобраться, чем в многомерной макаронине, множество раз пересекающейся сама с собой.


  1. playermet
    30.10.2024 15:55

    Пользователь: ищет что-то про Jujutsu
    Поисковик: Kaisen?


    1. PriFak
      30.10.2024 15:55

      опередил )
      я реально об этом же и подумал


  1. nuclight
    30.10.2024 15:55

    Натыкался на этот jj весной в поисках идей для своей DVCS. Увы, при том же гите как формате хранения ничего инновационного там архитектурно нет и быть не может - так, только CLI-удобства какие...

    Основная проблема jj такая же как у Mercurial, Bazaar и прочих — они не Git. Многие уже подсели на Github/Gitlab и не могут легко переключиться на jj. Инструменты и инфраструктура вокруг Git делают его стандартом для индустрии.

    И это, собственно, ключевой момент, который не понимает автор статьи - использование чего-то в качестве "стандарта" не отменяет ни других средств, ни исследований в этой области, которые со временем победят, если сумеют предложить что-то действительно новее и лучше. Двадцать лет назад таким "стандартом" для приложений была Windows - всё, нету этого, теперь Web, облака и мобилы. Еще через 20 лет и это перестанет быть стандартом, и т.д.


  1. Panzerschrek
    30.10.2024 15:55

    Интересно, но не практично. git стал отраслевым стандартом, с ним все умеют работать, куча инструментов под него заточено. Лучшие (в теории) альтернативы просто не могут в таких условиях существовать.


  1. feelamee
    30.10.2024 15:55

    Многие уже подсели на Github/Gitlab и не могут легко переключиться на jj. Инструменты и инфраструктура вокруг Git делают его стандартом для индустрии.

    Вы ведь сами сказали тут:

    Поддерживает чтение и запись в Git remote. Можете попробовать импортировать свой pet-project и поиграться с коммитами

    что jj может работать с git.

    Поэтому это решает проблему зависимости от инфраструктуры git.