Comments 28
Спасибо за статью и отдельное за понятный пример, зачем читателю эта штука. А то когда узнал впервые про jj и зашёл на сайт, сходу не понял, да и закрыл за ненадобностью кажущейся. Но тут дело скорее во мне, уже с гитом привык работать, в зубодробительных ситуациях переключаюсь на GUI какой-нибудь, опыта достаточно набил за годы.
Мне ещё понравился их log, — чуть репрезентативнее сравнение можно прямо в репозитории проекта посмотреть, — в сравнении с тем, что стандартно в git.
Ну и чтобы пользу комментарий какую-никакую нёс, вот что спрошу. Тем кто гитхуками пользуется, тяжело будет пересаживаться? Из коробки есть поддержка, не проверяли на своих задачах? Надеюсь бесшовно работают. Без гитхуков очень многим ненужно будет (да и с ними, хе-хе).
Поддержка нативных 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, который, по заверению пользователей, намного круче, но совсем другое. Тут я не пробовал, комментировать не буду.
Для начала JJ работает поверх бекенда Git, а это уже опасно в плане инкапсуляции особенностей поведения JJ, поскольку другие сотрудники и утилиты ничего о JJ не знают.
Без проблем - просто переключаюсь на старую версию, делаю hotfix.
Изменение старого коммита перепишет вам историю в Git. Под капотом там скорее всего что-то вроде
git checkout <commit>
git reset --soft
<ожидание коммита>
git rebase --onto ...Даже если JJ позволяет вам забить на конфликты, они неизбежно возникнут у других сотрудников и на серверах контроля версий просто из-за изменения истории.
jj git push -c @не просто отправляет изменения, но создает отдельную новую ветку
git push -u origin <название> сделает то же самое.
и сразу предлагает ссылку на создание Merge Request, если ваша система это поддерживает
Это фича сервера контроля версий, а не JJ.
Спасибо вам большое за ваш комментарий.
Для начала JJ работает поверх бэкенда Git, а это уже опасно в плане инкапсуляции особенностей поведения JJ, поскольку другие сотрудники и утилиты ничего о JJ не знают.
Да, вы правы, jj работает поверх git и сохраняет совместимость. Это как раз одна из его целей — не ломать экосистему. А в чем конкретно вы видите проблему?
Изменение старого коммита перепишет вам историю в Git. Под капотом там, скорее всего, что-то вроде.
Разница в том, что операции, которые в git требуют цепочки команд (reset, checkout, rebase и т.д.), в jj становятся атомарными и удобными. Плюс есть возможность откатить операцию, чего в git не хватает.
Про конфликты — абсолютно согласен, их никуда не деть. В своем примере я больше делал акцент на том, что при перепрыгивании с ветки на ветку не возникает локальных конфликтов, которые очень тормозят работу и заставляют тебя пользоваться stash.
И да, git push тоже может создать ветку, но в jj я могу выбрать «этап» разработки и получаю ссылку прямо в консоли.
А в чем конкретно вы видите проблему?
Да вот как раз в том, например, что вы можете на самом деле сделать ребейз общей ветки даже если не подозревали об этом. Для того я и привёл цепочку команд.
Кстати термин «изменение» может вводить в заблуждение, потому что Git всё же хранит не изменения, а снапшоты файлов, в отличие от, например, Fossil.
В jj вместо веток - закладки (bookmarks).
Я открою вам страшнейшую тайну про git... Хотя нет, не сегодня )
Свистоперделка для поиграться. Она даже не всё умеет, что умеет гит, но уже преподносится как что-то крутое и революционное, что уже можно использовать в работе.
Гит стал стандартом спустя много-много лет и много-много боли (перешедшим с других vcs). За это время накопились тонны информации по его косточкам. Может быть, на нашем веку эта зумерская погремушка ещё успеет стать рабочим инструментом, но её ждёт трудный путь.
когда нибудь, гит сделают с встроенной поддержкой бинарных файлов больших размеров. со встроенной поддержкой работы со срезами, как в свн и поддержкой папок. и жизнь наладится.
Весьма маловероятно.
Это крайне плохо ложится на концепцию локального репозитория. В котором все участники разработки будут хранить одновременно все версии всех блобов.
А вот добавить поддержку сбоку, этакий lfs на максималках, наверное могли бы.
майкрософты активно занимаются именно вот этим вот расширением, ибо у них там монорепа. Они и с большими файлами возились и с shallow clone и прочие оптимизации, чтобы оно могло с монорепами такого уровня работать.
Интересно. Как оно называется, не подскажите?
Ну для честности монорепо не имеет прямого отношения к размеру репозитория. Если в нем хранится только код (без внешних модулей, пакетов и т.д.) то сложно добиться огромного его размера.
С другой стороны если в репозитории хранить блобы, то его крайне просто сделать гиганским по размеру и без монорепов.
Scalar
Интересно. Как оно называется, не подскажите?
не очень понимаю про что вы спрашиваете.
Ну для честности монорепо не имеет прямого отношения к размеру репозитория
Слитые сорцы яндекса весили порядка 40 гигов и там практически все было кодом или конфигом. Яндекс тоже использует монорепо для своего кода, но у них там своя собственная система контроля версий.
А теперь представьте сколько лежит в репах майков. Так что размер репозитория вполне себе имеет значение. Положите исходники Windows и Visual Studio со всей историей хотя бы за последние 20 лет и наверняка это уже перекроет размер слитых исходников яндекса. Не сказать чтобы в таком формате с этим работать удобно. А уж как трафик растёт, когда разработчики / CI периодически клонируют репозитории для нужд разработки. Помножьте на тысячи разработчиков и десятки тысяч сборочных пайплайнов и цифры становятся совсем неприятными, а скорость разработки будет совсем не ахти просто на ожидании пока оно по сети передастся - это если работать в единой монорепе и держать весь код без ограничений каждый раз. Поэтому у них и до покупки гитхаба были патчи для гита, позволявшие клонировать только рабочие папки, а не всю репу целиком. Туда же версионирование всяких бинарных данных - шрифты, картинки, музыка и прочее - тот самый LFS. После покупки они их собственно доставили этот функционал уже в открытый гит. Worktree вроде тоже с их подачи появился, но это не точно.
гит сделают с встроенной поддержкой бинарных файлов больших размеров
Чем сейчас не устраивает partial clone?
git clone --filter='blobs:size=100k' <repo>
Подробней в статье The future of large files in Git is Git.
А потом замечаем: ошибка была в самом первом коммите. В feat: Add initial user authentication.
Что делать?
Не знаю, как у вас, у меня такое регулярно.
Коммитить fix в ветку new-feature а потом pull request + squash.
Вот тут так делали регулярно.
О, а тут ещё начальник прибегает с криком: "hotfix срочно!"
Ну в новую ветку переключаешься да и всё. Возможно, я чего-то не понял...
Могу немного поворчать, что судя по
git checkout -b new-feature
git освоен на уровне его состояния лет 10 назад. Git ведь тоже развивается в сторону удобства, появляются новые команды.
Конкретно для этой из примера:
git switch --create new-feature
А там, глядишь, и проблем станет меньше.
Справедливости ради, git add можно не делать, если не добавлялись новые файлы, а сразу писать git commit -am "message"
Это что-то типа MediaWiki для кода? Если да, то одобряю, мне нравится такой подход к истории правок и версиям.
Попробовал его однажды, попереключался между ветками, а потом посмотрел на историю через gitk и офигел, как половина экрана засрано тэгами этого jj. Демо было неплохим, но я видимо как-то не так работаю, ибо в такой проблемный флоу пока ни разу не попадал.
Не понял, зачем нужно переписывать историю комитов каждый раз когда хочется исправить ошибку. Может вы используете git как-то не так? Из плюсов jj вижу только более красивый git log, но возможностей git log мне хватает.
Надоело воевать с Git? Попробуй Jujutsu (jj), и вот почему он круче, чем кажется