Re[12]: Git: rebase vs merge или линейная история против спагетти
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 22.02.22 12:37
Оценка:
Здравствуйте, ·, Вы писали:

N>>·>Не знаком я с этим товарищем.

N>>Ну тогда просто знай, что переход BIND 8 -> 9 был сделан через написание кода с нуля. Вся старая история не была продолжена.
·>Бывает. Такая ситуация будет отражена в графе истории, что истории независимы и у них нет общей базы. Но причём обсуждаемый тут cherry-pick vs merge? Поможет ли gerrit? Или ты просто за жизнь рассуждаешь?

Ты абсолютизировал тут связь в истории, я привёл контрпример.
И вот он как раз в пользу подхода стиля cherry-pick (если не вообще format-patch + am): если нет общего базового коммита, git на попытку merge тупо сходит с ума, предлагая обе версии каждого файла с нуля.
Я с таким однажды возился, и таки пришлось каждый переносимый патч применять через am. (Cherry-pick не проходил тоже, а то было бы проще, но это потому, что поциэнт даже концы строк не нормализовал.)

N>>>>Но даже если без такого радикализма, 8-я версия, очень вероятно, будет сделана на релизной ветке, а не на транке (вообще не представляю себе, кто будет её делать на транке). И там может быть всё заметно иначе.

N>>·>Шо? Не понял. Когда писали 8ю версию, она была транком.
N>>Когда вводили принципиально новое — да. Когда релизили и патчили — уже нет.
·>Если патчили изначально бардаком, накатывая разные изменения в разные точки истории, то да — в хаосе не разобраться. С черрипиками будет вообще беда.

"В разные точки" это насколько разные? В >99% случаев, когда обнаруживается баг, определяется сразу, в какие ветки вносить его правку, и после одобрения это происходит одновременно со всеми целевыми ветками. В этом случае бардак минимизирован до следовых количеств.
У тебя есть какой-то типовой сценарий, когда надо собирать отдельный релиз из кучи правок вразнос? Так бывает?

N>>·>diverged branch. Если в 17 всегда мержить 8, то 17 не будет diverged от 8 и мержи упрощаются.

N>>Нет, не упрощаются. Часть правок от 8 не нужна, часть слишком сложно мержить из-за изменения стиля, расположения по файлам и всё такое, часть реализуется совсем иначе.
·>Ну и? Чем поможет cherry-pick? Вот merge помочь может — git может детектить перемещение расположения по файлам. А если ещё и rerere включить...

При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
rerere не приходилось использовать. Возможно, он и тут помог бы.

·>Да. Мне тоже подход gerrit нравится. Но это всё-таки заточено на PR процесс, а не на мерж между разными ветками.


Что такое "PR процесс", я не понял. Если разработку согласно тикетам, то да, где-то на это. Мерж между ветками — я писал рядом — там возможен, но обычно нафиг не нужен. Из всех команд его использовала только одна, с самым специфичным компонентом.

N>>Можно было вместо этого просто генерировать uuid на коммит, но их метод чуть надёжнее.

·>В gerrit это и делают — хуком генерят дополнительный uuid в коммит.

Ну, я имел в виду что это не то, что обычно называется UUID или GUID, хотя выполняет по сути ту же роль.

N>>Ещё работает связь по id тикета, который тоже должен быть в сообщении коммита.

N>>А сложные случаи всё равно требуют анализа задачи.
·>Во-во.

Да, но не кода напрямую. Код только отражение спецификации, а одна и та же функция в коде может решать множество разных задач. Или не решать.

·>А в чём гемморой проявлялся?


См. ниже.

N>>>>Из них делаются спецификации, из них тикеты с задачами и только из них — код. Он тут вообще "четвертичен", если не дальше.

N>>>>Клиентам отправляется продукт, а не "код из СКВ".
N>>·>Продукт-то из чего собирается? Из тикетов?
N>>И на что тут влияет, из чего собирается продукт?
·>С т.з. разработчика — результат работы — коммиты. И разбираться в графе истории проще, чем в тикетах, особенно если о виде графа заботятся, а не пихают всё что пихается.

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

N>>Я ничего не утрирую, всё на опыте. Вариант с мержем из предыдущих веток приводит к резкому усложнению сопровождения кода. В истории тупо мусор.

·>Можно какие-нибудь детали? Пример?

Открытого примера у меня нет, а основная проблема в том, когда начинаешь смотреть, что это смержено, и оказывается, что попадаешь на неактуальную фигню 15-летней давности и приходится регулярно отвлекаться, чтобы потом откидывать её.
С черипиками такого нет — приходит уже код достаточно свежего вида, а связь пусть даже с древнейшими багами обеспечивается за счёт других идентификаторов.
The God is real, unless declared integer.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.