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

N>·>Да я знаю. Но я не говорю о универсальном всемогутере. Если с проектом беда и бардак, то нужно выбирать способ более топорный и требующий больше возни. Но по умолчанию нужно делать как проще, а не в гамаке и стоя.
N>Ну вот так и делаем. И я фигею от того, что тебе почему-то способ с мержем целой ветки предшествующего релиза легче, чем те же черипики.
Как правило, все изменения в релизе надо мержить в последний код, притом сразу. Иначе бага поправленная в версии 8 возникнет снова при апргейде на 9ю. Клиентам такое, обычно, не нравится, мягко говоря.

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

N>·> Можно всё черрипикать, но тогда ты просто идёшь более сложным путём и создаёшь себе проблемы на пустом месте.
N>Наоборот, я всё упрощаю.
Ты создаёшь множество snowflake версий. С парой каждых надо внимательно разбираться копаясь в комментах джиры что где есть, а чего нет.

N>>>·>Ну и? Чем поможет cherry-pick? Вот merge помочь может — git может детектить перемещение расположения по файлам. А если ещё и rerere включить...
N>>>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
N>·>Хз, не уверен... но у меня сложилось впечатление, что при черрипиках нетривиальных конфликтов больше. Плюс черрипики это каджый коммит индивидуально, тогда как мерж — это сразу пачка, одно действие, один раунд разрешения конфликтов.
N>Вот как раз на этом ещё одна проблема мержей — что когда ты заметно разные ветки пытаешься мержить — можешь получить такую кашу, что вообще непонятно, что с ней делать.
А просто не надо создавать заметно разные версии. Версии должны не diverge в разные стороны, а старые версии должны быть behind новых. Не даром же их циферками нумеруют, подразумевают ЧУМ.

N>rerere, конечно, частично спасает. Но по опыту коллег — далеко не всегда.
N>Можно решать мержем по одному или несколько коммитов, но тогда разницы с черипиком тупо нет в качестве мержа (зато при черипике не прицепляется чужая неадекватная история).
Мерж по одному-нескольким как раз происходит по ходу пьесы, когда ты работаешь над конкретным изменением, а не через год, когда уже все всё забыли что там такое было и что с этим делать.

N>·>Плюс всякие запросы типа git log v1.2.3..v2.3.4 выдают меньше треша.
N>Что такое "треш" тут? Ты вместо реальных изменений видишь просто коммит "тут вмержили какую-то фигню"? Причём ты даже не видишь без явного запроса, что именно вмержили?
Мерж коммиты можно просто игнорировать. Даже ключик есть специальный --no-merges.

N>Это одна из тяжелейших проблем твоего подхода: пусть у тебя в ветке release/8 есть изменения, которые в принципе не предназначены идти в старшие ветки.
merge --strategy ours и всё: явно прописали в истории, что эти изменения не предназначены идти в старшие версии.

N>Ты сказал сидя например в release/9 "git merge release/8". У тебя есть мерж-коммит, поздравляю, но из него теперь надо вычистить всё, что не должно было идти в 9-ю и новее.
N>Например, там какую-то возможность выключили по принципу "оно глючит, мы в 8-й это не включаем". Как ты это будешь делать? Делать реверты всех коммитов, которые не должны были переходить в 9-ю? Ну, успехов в труде.
Да. Не вижу проблемы. Ты просто предполагаешь, что у тебя версии 8 и 9 изначально разъехались на километры и в репе хаос. Так просто не надо делать и хаоса не будет. Изначально 8 просто предок 9й. Как только добавили фикс в 8ю, мержим его в 9ю. Используя ours если мы заранее знаем, что не хотим этот конкретный фикс в 9й или revert впоследствии, если выясним это позже.

N>С черипиками те изменения, которые надо переносить, чётко определены и переносятся именно они.
И получаете хаос со снежинками.

N>·> Плюс bisect не спотыкается на лишних коммитах. И т.п.
N>bisect "спотыкается" ровно на том, что нужно. Если что-то сделано в этой ветке, оно и присутствует, причём в предельно явном виде — в виде конкретного коммита, отображённого диффом.
Каждая черрипикнутая копия коммита для git выгядит как независимый коммит и место где споткнуться.

N>·>sha1 коммита вроде ничем от guid не отличается... (ну кроме формата)
N>Он длиннее 160 бит вместо 128 (из которых в лучшем случае 122 меняются).
Ну да. И на что это влияет?

N>>>Открытого примера у меня нет, а основная проблема в том, когда начинаешь смотреть, что это смержено, и оказывается, что попадаешь на неактуальную фигню 15-летней давности и приходится регулярно отвлекаться, чтобы потом откидывать её.
N>·>Когда я прикручивал этот pipeline я почистил эти конюшни, но благо у нас код не такой старый, несложно было.
N>Ты в принципе не можешь почистить, если какие-то компоненты переписываются с нуля, какие-то принципиально реструктурируются. Хотя если у тебя в репе такого не происходит... слегка завидую, но это неинтересные тепличные условия.
strategy ours