Здравствуйте, ·, Вы писали:
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-летней давности и приходится регулярно отвлекаться, чтобы потом откидывать её.
С черипиками такого нет — приходит уже код достаточно свежего вида, а связь пусть даже с древнейшими багами обеспечивается за счёт других идентификаторов.