Jujutsu — истории успеха?

Есть ли тут кто-то, кому эта штука реально помогает в работе?

Языку программирования Rust исполнилось 10 лет (комментарий).

Прикольно. Только тег всё ещё не кликабелен :((

@unC0Rr расскажи подробнее про это чудо?

очередная никому не нужная попытка сделать гит луТше, расходимся

больше похожи на поиски проблемы под решение

У fossil так же было.

Уже год с лишним изо всех щелей слышу про сабж

Учитывая, что я о жидуджитсу как вцс опервые услышал от тебя, то у тебя очень странный информационный пузырь.

Есть ли тут кто-то, кому эта штука реально помогает в работе?

Есть. Во многом за счёт того, что ребейзить больше не мучительно больно.

Остальное это приятные дополнения.

То есть изо всех щелей ты слышишь про сабж, но пришёл зачем-то за историями успеха. А слышишь ты что, не истории успеха? Пусть те тебе и рассказывают.

Да чего тут рассказывать? Очень удобная штука как компромисс между доступом к гитовским репам и человеческим интерфейсом. Хотя формат гита ограничивает возможности jj, поддержка гитовских реп делает его намного привлекательнее. Основное отличие от гита - отсутствие стейджа, можно в любой момент оторваться от текущей работы над коммитом или даже мерджем с конфликтами и переключиться в другую ветку, например, для срочного фикса. Очень удобно править историю, все эти сквоши, ребейзы и прочее. Возможность просто сделать undo любой операции. Использую на работе и коллег пересадил, все довольны.

ребейзить больше не мучительно больно

оно автомагически фиксит конфликты?

Конфликты там первоклассная сущность, и костыли вроде git rerere не нужны. Какие-то конфикты, само собой, всё равно надо разрешать руками (хотя не обязательно это делать сразу же).

можно в любой момент оторваться от текущей работы над коммитом или даже мерджем с конфликтами и переключиться в другую ветку

stash? Да хоть склонируй копию репозитория и там делай свои быстрофиксы независимо от того репа где работаешь над коммитом или мерджем с конфликтами

Очень удобно править историю, все эти сквоши, ребейзы и прочее

куда уж проще то чем сквош и ребейзы

Короче типичная вкусовщина

Да хоть склонируй копию репозитория и там делай свои быстрофиксы независимо от того репа где работаешь над коммитом или мерджем с конфликтами

У — удобство.

Учитывая, что я о жидуджитсу как вцс опервые услышал от тебя, то у тебя очень странный информационный пузырь.

Я об этом читал на lobste.rs и HN. Там регулярно пишут о подобном софте.

Если у тебя лобстер в утюге, то это именно он (странный информационный пузырь) и есть.

Основное отличие от гита - отсутствие стейджа, можно в любой момент оторваться от текущей работы над коммитом или даже мерджем с конфликтами и переключиться в другую ветку, например, для срочного фикса.

Да, я читал, что автор – фанат Mercurial. Но одно только это – достаточно сомнительный плюс, потому как проще закоммитить побырому, переключиться и, по возвращении, сделать fixup.

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

Если у тебя лобстер в утюге, то это именно он (странный информационный пузырь) и есть.

Меня на лобстерах дважды забанили (плюс забанили чувака, который один из инвайтов кинул). Но как поток интересных статей и новостей оно куда живее ЛОРа. Вот ЛОР как раз до сраного пузыря скатился, и это печально :(((

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

Мне пока не приходилось фоллбечится в гит, хотя он используется как хранилище.

Мне пока не приходилось фоллбечится в гит, хотя он используется как хранилище.

А как же сходу jj git clone, jj git push и так далее?

git-worktree есть для этого.
git-clone потащит всю историю, что нежелательно.

You are in the middle of a refactoring session and your boss comes in and demands that you fix something immediately. You might typically use git-stash[1] to store your changes away temporarily, however, your working tree is in such a state of disarray (with new, moved, and removed files, and other bits and pieces strewn around) that you don’t want to risk disturbing any of it. Instead, you create a temporary linked worktree to make the emergency fix, remove it when done, and then resume your earlier refactoring session.

Ровно тот сценарий, о котором пишет unC0Rr.

git-worktree есть для этого.

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

ребейзить больше не мучительно больно

Никогда и не было, вы что-то не так делали.

да, пишут... Например про Pijul VCS.
Но толку от этого чтения, если везде в основном git.

Вот ЛОР как раз до сраного пузыря скатился, и это печально :(((

Зато это наш пузырь.
Тут можно местную обстановку обсудить.

Я имел в виду git без jj. А jj git clone, jj git push это как раз использование гита как хранилище.

ребейзить больше не мучительно больно

Никогда и не было, вы что-то не так делали.

Попробуй ветки с фичей с одной версии ядра на другую заребейсить. Это бывает весьма больно, куда проще коммиты по одному через cherry-pick переносить. Прозреваю, что в других проектах такого масштаба с активной разработкой не лучше. Git вообще на больших проектах весьма больно пользовать.

да, пишут… Например про Pijul VCS.

Пихулю уже лет 10. До ЛОРа как видишь с диким запозданием доходит.

Но толку от этого чтения, если везде в основном git.

А это не так важно, git можно использовать как формат хранения и протокол, саму vcs можно поверх вообще любую взять и хранить её штуки в метаданных гитовых объектов. JJ вот ровно так и делает.

Зато это наш пузырь. Тут можно местную обстановку обсудить.

Толку-то её обсуждать? Всем давно всё ясно, все всех знают, новой публики нет, одни старпёры остаются.

Попробуй ветки с фичей с одной версии ядра на другую заребейсить.

Я и говорю, че-то не то делаете, если эти версии сильно разошлись и не апдейтались девелоперами хз сколько. Или разрабы фичи забили на совместимость. Это уже бэкпортирование, ребейс не при чем.

Это бывает весьма больно, куда проще коммиты по одному через cherry-pick переносить.

Ребейс под капотом и есть куча pick, но все ваши страдания от лобовых попыток порешать результат сложносочиненной операци, когда уже поздно. А в интерактиве оно на первом конфликте останавливается, решается конфликт, комит, едем дальше. И pick происходят сами, руками конечно тоже можно, но зачем.

Я и говорю, че-то не то делаете, если эти версии сильно разошлись и не апдейтались девелоперами хз сколько. Или разрабы фичи забили на совместимость. Это уже бэкпортирование, ребейс не при чем.

Всё куда проще: гит не знает, какой коммит к какой ветке принадлежит, потому что ветка – просто (плавающий) указатель на коммит. Поэтому ребейс с одной версии на другую потянет вагон левых коммитов.

Если бы коммиты принадлежали веткам, как это сделано в, опять же, том же Mercurial, это «бэкпортирование» вылилось бы ровно в одну команду плюс разруливание конфликтов.

Ребейс под капотом и есть куча pick

И да, и нет. Ребейс под капотом – это в том числе сравнение веток, и вот оно в гите сделано через член, потому что смотри выше.

Поэтому ребейс с одной версии на другую потянет вагон левых коммитов.

Не потянет, если ерундой не заниматься.

Ребейс под капотом – это в том числе сравнение веток, и вот оно в гите сделано через член, потому что смотри выше.

Потому что дуинг ит вронг и хотение странного от инструмента, в котором и не было и не планировалось функции «сделать через телепатию по красоте, чтоб не применять голову», см. выше. Сравнение веток — это вообще глазами делается, в процессе интеректив ребейса. В удобной внешней диффалке. Все остальное нытье от попыток спидранить нетривиальный переезд, результат которого один фиг надо посмотреть глазами.

Я вот недавно пробовал в конфликте заломать хулигану руку приёмом дзю-дзюцу, но, видно, давно не практиковался, фигня вышла.

Не потянет, если ерундой не заниматься.

Ты явно не понимаешь, что пишешь тут.

хотение странного от инструмента, в котором и не было и не планировалось функции

Вот именно. Авторы других инструментов подумали и такую фичу запланировали. Авторы гита нишмагли. В люнексе всегда так, ксо жалению.

Сравнение веток..в процессе интеректив ребейса

ловите норкомана, он rebase -i делает не для сквоша локальной истории!!

git-clone потащит всю историю

--depth 1 же. Плюс клонировать не из сети, а локальную копию. Хотя тут с пушки могут быть проблемы - смотреть надо.

Всё куда проще: гит не знает, какой коммит к какой ветке принадлежит, потому что ветка – просто (плавающий) указатель на коммит. Поэтому ребейс с одной версии на другую потянет вагон левых коммитов.

Ерунду вы написали. Он ищет общий коммит и от него переставляет все остальные коммиты.

То, что чем дальше в лес, тем сложнее сердиться, не секрет в общем-то. Потом ребейз на левом надо делать периодически, если ветка затянулась.

Так что поддержу оратора выше: что-то иВы делаете не так.

jj - говно на расте

А судя по комментам, тут просто гитом кто-то пользоваться не умеет

Ерунду вы написали. Он ищет общий коммит и от него переставляет все остальные коммиты.

Ага. Поэтому он зачастую не знает, с какого коммита начинать, и предлагает херню.

У нас тут отдельная команда ядерщиков вообще свой код в виде патчей на ядро хранят, потому постоянный ребейс туда-сюда – просто хтонь какая-то

Так что поддержу оратора выше: что-то иВы делаете не так.

Используем git, когда требуется нормальная система контроля версий. Не по своей вине, тащемта :(((

ну я

не путается под ногами в отличие от беспомощной отрыжки LKML

Какого размера проект, где ты его применяешь? Сколько активных веток и разработчиков? Кроме тебя им кто-то пользуется?

jj - говно на расте

Очень соболезную

Git 2.55 Released With Rust Support Enabled By Default

Какого размера проект, где ты его применяешь?

да все проекты, до которых дотягиваюсь в общем-то. самый большой — 1.8M LOC.

Сколько активных веток и разработчиков?

По-разному, до десятков.

Кроме тебя им кто-то пользуется?

хз, может и нет, но прелесть в том, что это не имеет никакого значения — разве только что мои PRs rebaseятся необычно быстро.

киллерфича — возможность разрулить конфликт когда угодно, а не НЕМЕДЛЕННО ТУТ ЖЕ как у git.

ещё киллерфича — возможность почти тривиально работать сразу над несколькими ветками (см. mega-merge workflow), в т.ч. и потому, что с увеличением количества веток кол-во церемоний растёт в худшем случае линейно, тогда как с git оно же растёт чуть ли не экспоненциально (я пробовал).

и наконец jj undo, которое позволяет взять и отменить любую операцию с репозиторием (нет, reflog недостаточно)

Окей, спасибо большое! Я вот примерно такой отзыв и хотел увидеть.

Ещё вопрос: как конфликты сохраняются в истории? Я могу сохранить конфликт на одной машине, сделать push и потом разгрести на другой? Что увидят юзеры гита при этом?

Ещё раз, медленно: Вы. Что-то. Не. Понимаете.

Ага. Поэтому он зачастую не знает, с какого коммита начинать, и предлагает херню.

ИИ головного мозга уже? гит - программа и действует по алгоритму.

Было:

A---B---C---D---E---F   main
     \
      G---H---I          feature

Стало:

A---B---C---D---E---F       main
                     \
                      G'---H'---I'   feature

Если три ветки.

Было:

A---B---C                 main
     \
      D---E---F           feature1
           \
            G---H---I    feature2

git rebase --onto main feature1 feature2

Стало:

A---B---C                     main
     |    \
     |     G'---H'---I'       feature2
     \
      D---E---F               feature1

Если случилась херня и надо только часть веток перенести:

A---B---C                         main
     \
      D---E---F---G---H           feature

git rebase --onto main F feature

A---B---C               main
         \
          G'---H'        feature

     D---E---F           (осиротели, доступны только через reflog)

Альтернативная нотация: git rebase --onto main G~ feature

Я фигею порой с программистов. Гитом люди пользуются каждый день. Вполне достойная причина изучить инструмент. Но нет, мы будем изучать новый, модный.

У тебя безумно упрощённый сценарий, чувак. Тут-то понятно что git хватит, а вот в куда более сложных сценариях придётся либо страдать, либо допиливать git, либо приделывать костыли (jj).

как конфликты сохраняются в истории?

обычным коммитом

Я могу сохранить конфликт на одной машине, сделать push и потом разгрести на другой?

ДА. Я даже не знал, что так можно вообще.

Что увидят юзеры гита при этом?

обычный коммит, с конфликтами завернутыми в https://docs.jj-vcs.dev/latest/conflicts/#conflict-markers

Используем git, когда требуется нормальная система контроля версий.

Подожди ещё (не знаю сколько времени), я нормальную vcs как раз доделываю.

Ну так расскажи. Я просто не представляю, что там может такого взяться.

Единственный вариант: 3 месяца не синхронизироваться. Но тут без вариантов проблем выше крыши будет.

Ну так расскажи. Я просто не представляю, что там может такого взяться.

Да банальный пример. Ты работаешь над ядром, форкнул ветку от тега, например, 6.10, а потом тебе надо её перенести на тег 6.18. Можешь сам склонировать ядро и попробовать повторить этот фокус через ребейс. Тебя ждут интересные приключения.

Это же вот ровно то, про что я написал. То, что будет много сэкаса, охотно верю, но связано это будет с тем, что разница межу 6,18 и 6,10 большая - там внутри всё поменялось.

(Разница составляет примерно 1 год и 5 месяцев.) - Уф…

Нет. Это связано с тем, что git, как я написал выше, не сохраняет в коммитах информацию о том, к какой ветке они принадлежат, и приходится руками выдирать коммиты из лога и сделать cherry-pick циклом. И это придётся делать даже если твои коммиты не будут создавать конфликтов при переносе, тут проблема именно с выделением нужного подмножества. Вот JJ с этим, судя по всему, помогает.

git rebase --onto 6.18 6.10 feature

Попробуй. Потом расскажешь.

Это буквально тоже самое, что Черри пик.

Попробуй. Потом расскажешь.

Пробовал. Тянет тучу лишних коммитов, которые были в 6.10 но отсутствуют в 6.18. Приходится добавлять -i и руками выбирать.

Ещё есть отдельный карнавал, когда работаешь не с ванильным ядром, а с вендорскими ветками, и тебе нужно перенести свой код с вендорской 6.10 на 6.18, где множество вендорских коммитов может радикально отличаться, потому что, например, часть из них заапстримили в другом формате. git такое вообще не вывывозит. Опять же, всё это тянется из того факта, что в метаданных коммитов git нет никакой информации о ветках.