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

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

не просто луТше, а безопасТнее, оно же на rs

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

«Нормальная» в смысле «как у всех», а не «хорошая».

не сохраняет в коммитах информацию о том, к какой ветке они принадлежат,

да, не сохраняет.

и приходится руками выдирать коммиты из лога и сделать cherry-pick циклом

это нужно в случае, если после создания feature ветки были мержи feature и upstream веток.

тут проблема именно с выделением нужного подмножества.

Конкретно в примере с git rebase --onto 6.18 6.10 feature проблемы с выделением нужного подмножества быть не должно. Нужное подмножество это коммиты в цепочке от тега 6.10 до коммита, на который указывает feature ref.

(попробую проверить натурным экспериментом, как только будет время склонировать kernel)

Вот JJ с этим, судя по всему, помогает.

так ведь JJ тоже не хранит принадлежность к ветке, как я понимаю.

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

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

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

открою страшную тайну, git rebase - это и есть цикл таких черри-пиков

И это придётся делать даже если твои коммиты не будут создавать конфликтов при переносе, тут проблема именно с выделением нужного подмножества

открой для себя git rebase -i, в котором ты можешь выбрать какие угодно коммиты для перебазирования. А также соответствующие опции CLI, кури man git-rebase. Если у тебя там куча лишнего, то это значит только то что ты не умеешь пользоваться гитом и например перебазируешь не туда, откуда отпочковывался, перед этим делал merge вместо rebase, и т.п.

В общем, спасибо всем отписавшимся по теме. Пойду читать маны по jj. К нему ещё приблуду для Emacs в стиле magit завезли, так что выглядит весьма вкусно.

ловите норкомана

Да, никуда не уходи, за тобой уже выехали.

не для сквоша локальной истории!!

Божечки, а результат сквоша вы потом тоже глазами не смотрите и надеетесь на свежий libastral?

вот в куда более сложных сценариях

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

отписался от темы, в другой раз ставь тег «нытьё неосилятора»

открою страшную тайну, git rebase - это и есть цикл таких черри-пиков

Ему уже открывали выше, он там захотел чтоб за него пронзали через астрал чего он хочет при сравнении веток.

Unlike most other VCSs, Jujutsu will automatically create commits from the working-copy contents when they have changed. Most jj commands you run will commit the working-copy changes if they have changed. The resulting revision will replace the previous working-copy revision.

Also unlike most other VCSs, added files are implicitly tracked by default.

Спасибо. Не надо нам такого.

Вот. Я тоже терпеть не могу, когда мелкие инструменты называют словами из повседневной жизни. Лично по мне, исключения здесь уместны только для фундаментальных вещей типа ОС и языков программирования, ну или если там какой новый протокол для инета изобретут вместо IP, на который все будут переходить, тогда другое дело.

Тяжело, наверно, на линуксе с такими взглядами.

Почему? Очень удобно.

А с какого бодуна всё, что я делаю в моей рабочей копии, должно быть закоммичено? У меня там может быть куча экспериментов в разных временных ветках, которые я удалю на следующий день. Для нормальной работы должно быть чёткое разграничение между «просто файлы» и индекс. Как в гит.

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

И в чём противоречие с моделью работы jj?

Иногда и нет никаких веток. Иногда это просто временные файлы, которые я удаляю через «git rm -fr». И тогда я не хочу никаких коммитов и версионирования для быстрых экспериментов. Гит не ограничивает меня в моих режимах работы с кодом.