LINUX.ORG.RU

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

 , jujutsu, ,


0

4

Привет, чят!

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

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

P.S. тут нет тега jujutsu. Можно его добавить?



Последнее исправление: dataman (всего исправлений: 2)
Ответ на: комментарий от ant1

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

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

ant1
()
Ответ на: комментарий от yorshka

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

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

littlechris ★★★
()
Ответ на: комментарий от yorshka

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

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

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

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

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

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

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

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

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

MirandaUser2 ★★
()
Ответ на: комментарий от yorshka

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

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

bbc69
()
Ответ на: комментарий от yorshka

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

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

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

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

Lrrr ★★★★★
()
Ответ на: комментарий от ant1

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

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

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

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

anonymous
()
Ответ на: комментарий от yorshka

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

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

anonymous
()
Ответ на: комментарий от Lrrr

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

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

anonymous
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария