Для начала JJ работает поверх бэкенда Git, а это уже опасно в плане инкапсуляции особенностей поведения JJ, поскольку другие сотрудники и утилиты ничего о JJ не знают.
Да, вы правы, jj работает поверх git и сохраняет совместимость. Это как раз одна из его целей — не ломать экосистему. А в чем конкретно вы видите проблему?
Изменение старого коммита перепишет вам историю в Git. Под капотом там, скорее всего, что-то вроде.
Разница в том, что операции, которые в git требуют цепочки команд (reset, checkout, rebase и т.д.), в jj становятся атомарными и удобными. Плюс есть возможность откатить операцию, чего в git не хватает.
Про конфликты — абсолютно согласен, их никуда не деть. В своем примере я больше делал акцент на том, что при перепрыгивании с ветки на ветку не возникает локальных конфликтов, которые очень тормозят работу и заставляют тебя пользоваться stash.
И да, git push тоже может создать ветку, но в jj я могу выбрать «этап» разработки и получаю ссылку прямо в консоли.
Поддержка нативных Git-хуков в Jujutsu находится в разработке.
Сложность в том, что философия jj сильно отличается от Git. jj не использует классическую staging area, а также имеет другой подход к коммитам (рабочая копия - это всегда коммит). Из-за этого стандартные Git-хуки, такие как pre-commit и post-commit, которые завязаны на состояние HEAD и staging area, просто не имеют смысла в рабочем процессе jj. Разработчики jj планируют внедрить собственную систему native hooks в будущем, которая будет работать с концепциями jj (например, на уровне транзакций).
Пока что многие обходятся через alias: делают commit-with-checks и push-with-checks, комбинируя pre-commit с jj - это рабочий временный вариант. Я лично использую просто pre-commit run --all-files.
Также есть jj fix, который, по заверению пользователей, намного круче, но совсем другое. Тут я не пробовал, комментировать не буду.
Information
Rating
Does not participate
Location
Тюмень, Тюменская обл. и Ханты-Мансийский АО, Россия
Спасибо вам большое за ваш комментарий.
Да, вы правы, jj работает поверх git и сохраняет совместимость. Это как раз одна из его целей — не ломать экосистему. А в чем конкретно вы видите проблему?
Разница в том, что операции, которые в git требуют цепочки команд (
reset,checkout,rebaseи т.д.), в jj становятся атомарными и удобными. Плюс есть возможность откатить операцию, чего в git не хватает.Про конфликты — абсолютно согласен, их никуда не деть. В своем примере я больше делал акцент на том, что при перепрыгивании с ветки на ветку не возникает локальных конфликтов, которые очень тормозят работу и заставляют тебя пользоваться stash.
И да,
git pushтоже может создать ветку, но в jj я могу выбрать «этап» разработки и получаю ссылку прямо в консоли.Поддержка нативных Git-хуков в Jujutsu находится в разработке.
Сложность в том, что философия jj сильно отличается от Git. jj не использует классическую staging area, а также имеет другой подход к коммитам (рабочая копия - это всегда коммит). Из-за этого стандартные Git-хуки, такие как pre-commit и post-commit, которые завязаны на состояние HEAD и staging area, просто не имеют смысла в рабочем процессе jj.
Разработчики jj планируют внедрить собственную систему native hooks в будущем, которая будет работать с концепциями jj (например, на уровне транзакций).
Пока что многие обходятся через alias: делают commit-with-checks и push-with-checks, комбинируя pre-commit с jj - это рабочий временный вариант. Я лично использую просто
pre-commit run --all-files.Также есть
jj fix, который, по заверению пользователей, намного круче, но совсем другое. Тут я не пробовал, комментировать не буду.