Здравствуйте, netch80, Вы писали:

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

N>·>Если патчили изначально бардаком, накатывая разные изменения в разные точки истории, то да — в хаосе не разобраться. С черрипиками будет вообще беда.
N>"В разные точки" это насколько разные? В >99% случаев, когда обнаруживается баг, определяется сразу, в какие ветки вносить его правку, и после одобрения это происходит одновременно со всеми целевыми ветками. В этом случае бардак минимизирован до следовых количеств.
N>У тебя есть какой-то типовой сценарий, когда надо собирать отдельный релиз из кучи правок вразнос? Так бывает?
Самый простой путь — начать вносить багфикс в самую поддерживаемую раннюю версию и потом мержить в следующие по возрастанию. Можно всё черрипикать, но тогда ты просто идёшь более сложным путём и создаёшь себе проблемы на пустом месте.

N>>>·>diverged branch. Если в 17 всегда мержить 8, то 17 не будет diverged от 8 и мержи упрощаются.
N>>>Нет, не упрощаются. Часть правок от 8 не нужна, часть слишком сложно мержить из-за изменения стиля, расположения по файлам и всё такое, часть реализуется совсем иначе.
N>·>Ну и? Чем поможет cherry-pick? Вот merge помочь может — git может детектить перемещение расположения по файлам. А если ещё и rerere включить...
N>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
Хз, не уверен... но у меня сложилось впечатление, что при черрипиках нетривиальных конфликтов больше. Плюс черрипики это каджый коммит индивидуально, тогда как мерж — это сразу пачка, одно действие, один раунд разрешения конфликтов.
Плюс всякие запросы типа git log v1.2.3..v2.3.4 выдают меньше треша. Плюс bisect не спотыкается на лишних коммитах. И т.п.

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

N>>>Можно было вместо этого просто генерировать uuid на коммит, но их метод чуть надёжнее.
N>·>В gerrit это и делают — хуком генерят дополнительный uuid в коммит.
N>Ну, я имел в виду что это не то, что обычно называется UUID или GUID, хотя выполняет по сути ту же роль.
sha1 коммита вроде ничем от guid не отличается... (ну кроме формата)

N>·>С т.з. разработчика — результат работы — коммиты. И разбираться в графе истории проще, чем в тикетах, особенно если о виде графа заботятся, а не пихают всё что пихается.
N>Мне и большинству моих коллег — разбираться в графе коммитов не проще. Часто, наоборот, сложнее. А "всё что пихается" это как раз про код 15-летней давности.
Я этот процесс в jenkins pipeline присобачил. При сборке очередного фикса в релизной ветке, вначале происходит мерж в develop. И проблем с мержами/черрипикингом у нас просто не стало.

N>>>Я ничего не утрирую, всё на опыте. Вариант с мержем из предыдущих веток приводит к резкому усложнению сопровождения кода. В истории тупо мусор.
N>·>Можно какие-нибудь детали? Пример?
N>Открытого примера у меня нет, а основная проблема в том, когда начинаешь смотреть, что это смержено, и оказывается, что попадаешь на неактуальную фигню 15-летней давности и приходится регулярно отвлекаться, чтобы потом откидывать её.
Когда я прикручивал этот pipeline я почистил эти конюшни, но благо у нас код не такой старый, несложно было.

N>С черипиками такого нет — приходит уже код достаточно свежего вида, а связь пусть даже с древнейшими багами обеспечивается за счёт других идентификаторов.
Ну да... garbage in, garbage out.