tgoop.com/dereference_pointer_there/9437
Last Update:
#prog #article #amazingopensource
Jujutsu (jj) — система контроля версий, которая концептуально проще git и при этом мощнее.
Неплохой (но местами устаревший) обзор Jujutsu — jj init — сделал Chris Krycho. Также есть пока что неполный туториал от Стива Клабника, который тот написал главным образом для того, чтобы самому лучше разобраться с Jujutsu. Этот туториал даже рекомендуется в официальной документации.
Сразу скажу: jj работает поверх git, так что её можно поставить поверх имеющегося репозитория и потом без проблем удалить. (у jujutsu также есть нативный бекенд, но он пока не готов и не рекомендуется к использованию)
Что же такого примечательного в этой VCS? Попробую объяснить (но лучше почитайте по ссылкам, чесслово, там хорошо описано). В обоих описаниях бросается в глаза наличие операций, описанных в Where are my Git UI features from the future?.
Как и git, jj идейно работает на снапшотах файловой системы. В отличие от git, коммиты в jj напоминают объекты в ООП: они мутабельны и имеют идентичность, которая остаётся постоянной при изменениях самих коммитов — да, в том числе при ребейзах.
В отличие от git, в jj нет отдельной стадии стейджинга изменений и фиксации коммита. Более того, jj вообще не использует индекс — jj отслеживает изменения файлов и автоматически записывает их в текущий коммит (не волнуйтесь, есть средства для разбиения изменений). Для того, чтобы закончить с текущим коммитом, достаточно вызвать jj new для создания нового коммита, который отпочковывается от текущего. Описание для этого вводить необязательно — его можно добавить задним числом. Недостаток этого решения — большинство инструментов поверх git предполагают использование индекса и потому не очень хорошо стыкуются с jj.
Как я уже сказал, описание коммитов можно добавлять и менять в любой момент, вне зависимости от того, какой коммит текущий.
Ветки в jj анонимны, и это взрывает мозг тем, кто учился VCS на git (мне в том числе). Именованные ветки из git доступны в jj под именем bookmarks, и, в отличие от git, эти указатели не смещаются автоматически при добавлении дочерних коммитов — для этого нужно вызвать отдельную команду. Это выглядит неудобным, но по факту это даёт некоторые преимущества. Одно из них — нет нужды придумывать имя для каждого логического изменения. Оно требуется лишь тогда, как нужно расшарить изменения с другими. Другое — если в локальной копии слишком много изменений и стало понятно, что они идут куда-то не туда, можно просто откатиться до ветки (при условии, что локально её не двигали) и просто дропнуть коммиты после неё.
Коммиты можно свободно двигать в истории. В отличие от git rebase, имена коммитов после этого не меняются.
Ребейз и мердж в jj всегда успешно завершаются. Это не означает, что конфликты невозможны. Но в jj конфликты являются первоклассными значениями. Это позволяет слить несколько последовательностей коммитов в одну и разобраться с конфликтами позднее (и потом, возможно, слить разрешения конфликтов с мердж-коммитами).
Команда jj undo отменяет действие предыдущей команды. Дико не хватает этого в git.
Почти все команды jj позволяют указывать коммиты, на которых они действуют (и используют текущий коммит, если этот аргумент не указан). Более того, это может быть несколько коммитов — или revset в терминологии jj. Задавать revset-ы можно при помощи отдельного достаточно мощного языка выражений. В качестве побочного эффекта это означает, что, помимо всего прочего, в jj можно сделать мердж больше двух веток сразу.
Например, для того, чтобы просмотреть все локальные "ветки" (коммиты без дочерних коммитов), можно использовать jj log -r 'heads(all())'. all() возвращает все коммиты в репе, а heads извлекает из набора коммитов те, у которых нет дочерних. Если этого недостаточно и нужно добавить контекста — скажем, по два родительских коммита — можно использовать jj log -r 'ancestors(heads(all()), 2)'. (это лишь мой пример, по умолчанию jj log использует несколько более полезный формат)
BY Блог*
Share with your friend now:
tgoop.com/dereference_pointer_there/9437