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

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

Вот именно что "как правило". Главное, что исключения надо потом специально обходить.

N>>Я не о том. Что ты будешь делать, если тебе нужно собрать релиз из фич, которые просто не соответствуют никакому конкретному известному релизу?
·>Не надо так делать. Или я не очень понимаю зачем так вообще делать? Собирать какую-то уникально неповторимую версию, с которой невозможно без седых волос проапгедиться ни на какую другую, т.к. неизвестно чем одна сборная солянка отличается от другой.

Если зафиксировать как ветку, то проблем сильно меньше. Кстати, именно тут и можно мержить — проблем с этим меньше.

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

Не понимаю этого термина.

·> С парой каждых надо внимательно разбираться копаясь в комментах джиры что где есть, а чего нет.

1. Джиру в топку, если там сложно копаться.
2. В чём копаться-то? Есть метаданные тикета и есть указание релизов, в которые попали правки из него.

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

На практике так не бывает. Разные версии чуть по-разному развиваются. Одна и та же функциональность как для юзера может быть реализована разным кодом в разных местах.

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

Ну так и черипик делается именно сразу же, а не когда забыли, зачем он был нужен.

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

Ну тогда ты не увидишь, что в них собственно изменилось. Это ещё хуже — без такого ключа хотя бы есть намёк, что надо что-то уточнять.

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

И так на каждое изменение. То есть тебе нужно что-то изменив в 8-й тут же примержить это в 9-ю формально, но за счёт ours реально ничего не мержить. И не забыть это сделать, потому что если не сделать, то потом оно взорвётся на следующем реальном мерже, где не будет никакого ours.
Тебе не кажется, что ты сам себя регулярно сажаешь на зажжённую пороховую бочку?

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

Нет, всё просто и понятно, и без сидения на горящем порохе.

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

Да, выглядит. Нет, спотыкаться не на чем.

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

Мерж, который не мерж, только для того, чтобы потом не взрываться. Шарман, девочки.

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

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

N>>>Я не о том. Что ты будешь делать, если тебе нужно собрать релиз из фич, которые просто не соответствуют никакому конкретному известному релизу?
N>·>Не надо так делать. Или я не очень понимаю зачем так вообще делать? Собирать какую-то уникально неповторимую версию, с которой невозможно без седых волос проапгедиться ни на какую другую, т.к. неизвестно чем одна сборная солянка отличается от другой.
N>Если зафиксировать как ветку, то проблем сильно меньше. Кстати, именно тут и можно мержить — проблем с этим меньше.
Не понимаю что значит "зафиксировать как ветку".
Проблема не в том, что как где зафиксировать, что бы это ни значило, а в семантике нумерации версий. Если я, как пользователь, пользуюсь версией 1.2.3 и решил проапгрейдиться до 2.3.4, то я хочу быть уверенным, что у меня не вылезет тот же баг, который пофиксили в 1.2.1. Т.е., всё что было сделано в релизе 1.* должно работать в 2.*.
Вот правильно поставленный процесс мержей это обеспечивает. А черри-пикинг — всё приходится делать вручную, приходится каким-то другим способом вести учёт.

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

N>·> С парой каждых надо внимательно разбираться копаясь в комментах джиры что где есть, а чего нет.
N>1. Джиру в топку, если там сложно копаться.
Да неважно. Любую трекинговую систему или что там у вас. История кода должна храниться в графе истории, для этого предназначенным, а не где-то в стороне.

N>2. В чём копаться-то? Есть метаданные тикета и есть указание релизов, в которые попали правки из него.
Каким образом быть уверенным, что данные в тикетах отражают реальное состояние в коде? Мамойклянусем?

N>>>Вот как раз на этом ещё одна проблема мержей — что когда ты заметно разные ветки пытаешься мержить — можешь получить такую кашу, что вообще непонятно, что с ней делать.
N>·>А просто не надо создавать заметно разные версии. Версии должны не diverge в разные стороны, а старые версии должны быть behind новых. Не даром же их циферками нумеруют, подразумевают ЧУМ.
N>На практике так не бывает.
Это как раз то, на что был заточен git. Вот тут сплошные мержи из тагов (т.е. релизов). Попробуй найди черрипик.
Подход с черрипиками это то что творилось во всяких svn.
Вот тут от автора: cherry-pick shouldn't be *common*. А у тебя оно основная часть твоих процессов.

N>Разные версии чуть по-разному развиваются. Одна и та же функциональность как для юзера может быть реализована разным кодом в разных местах.
"чуть по разному" на языке git означает conflict resolution и мерж записывает в историю это соответствующим образом. cherry-pick с конфликтом это тупо отдельный коммит, никак не связанный с существующим, даже patch-id будет другим, что ломает алгоритмы conflict resolution.

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

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

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

N>Тебе не кажется, что ты сам себя регулярно сажаешь на зажжённую пороховую бочку?
Я не сажаю, ещё чего. jenkins pipeline этим занимается.

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

N>·>strategy ours
N>Мерж, который не мерж, только для того, чтобы потом не взрываться. Шарман, девочки.
Чё? Это стратегия мержа.

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

N>>Вот именно что "как правило". Главное, что исключения надо потом специально обходить.
·>Не знаю как у вас, но обычно принято не кормить клиентов старыми багами.

"Учу читать. Дорого."
Я писал, почему там нет "старых багов". Повторяться не хочу.

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

Создать ветку с адаптацией под конкретного кастомера.

·>Проблема не в том, что как где зафиксировать, что бы это ни значило, а в семантике нумерации версий. Если я, как пользователь, пользуюсь версией 1.2.3 и решил проапгрейдиться до 2.3.4, то я хочу быть уверенным, что у меня не вылезет тот же баг, который пофиксили в 1.2.1. Т.е., всё что было сделано в релизе 1.* должно работать в 2.*.
·>Вот правильно поставленный процесс мержей это обеспечивает.

Нет, не обеспечивает. Описанные тобой меры работают только в простейших случаях.
Но это не главное тут:

·> А черри-пикинг — всё приходится делать вручную, приходится каким-то другим способом вести учёт.

А мержить, значит, у тебя автомат настроили. Тогда кто этому автомату объясняет, что мержить в реале, а что только формально (ours)? А конфликты тоже автомат решает?
Нифига себе у тебя искусственный интеллект завёлся.

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

Нет, не создаю. И не понимаю, чем моё описание могло вызвать такие фантазии.

N>>·> С парой каждых надо внимательно разбираться копаясь в комментах джиры что где есть, а чего нет.
N>>1. Джиру в топку, если там сложно копаться.
·>Да неважно. Любую трекинговую систему или что там у вас. История кода должна храниться в графе истории, для этого предназначенным, а не где-то в стороне.

Не должна вся история там храниться. Код — это только код. Множество факторов, например, почему была выбрана такая архитектура и такая реализация, не могут храниться в коде.

N>>2. В чём копаться-то? Есть метаданные тикета и есть указание релизов, в которые попали правки из него.
·>Каким образом быть уверенным, что данные в тикетах отражают реальное состояние в коде? Мамойклянусем?

Организацией процесса разработки. "Мамойклянусь" это у тебя с "замержим, чтобы не глёбнуло потом".

·>Это как раз то, на что был заточен git. Вот тут сплошные мержи из тагов (т.е. релизов). Попробуй найди черрипик.

Разуй глаза и посмотри не только на транковую ветку, а и на то, из чего делаются стабильные ветки ядра (даже если "ванильные").
Вот раз, вот два черипики, а вот оригинал. Заметь, commit id оригинала (то есть окончательно принятый в транк) попал в сообщение коммита в черипиках, то есть они были сделаны уже после высочайшего одобрения.

·>Подход с черрипиками это то что творилось во всяких svn.
·>Вот тут от автора: cherry-pick shouldn't be *common*.

А полностью прочитать сообщение не хочешь? Или это уже пошла фигурная резьба по квотингу? Весь контекст определяет только транковую разработку. И к тому же там объясняется, почему у него "the reason I ask people to not do lots of merges", что совсем не в пользу твоих подходов.

·> А у тебя оно основная часть твоих процессов.

Да. Точно так же как сейчас в linux kernel за пределами транка.

N>>Разные версии чуть по-разному развиваются. Одна и та же функциональность как для юзера может быть реализована разным кодом в разных местах.
·>"чуть по разному" на языке git означает conflict resolution

Язык git тут ни при чём. Например, v8 делает настройку бриджа через ebtables, а v9 — через nftables. Или в v8 обмен данными на своей оболочке вокруг старого AJAX, а v9 — через React.
Один и тот же баг может лечиться в них заметно по-разному, мерж средствами git не поможет.

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

Зачем мудохаться с мержем, когда черипик проще, понятнее, контролируемее и надёжнее?

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

OK, понял. В моём варианте такой запрос лога просто не выполнится — нет прямого пути между этими версиями. Этот путь — артефакт твоего подхода и имеет смысл только в его рамках.

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

Разница в том, что черипик это явное действие: его надо сделать, чтобы получить результат. Контроль прямой и явный — не сделал, сразу видно.
Фиктивный мерж твоего стиля это действие, которое если не сделать, то взорвётся не сразу, а потом. Факт пропуска не очевиден, требуются специальные костыли, чтобы его обеспечивать. Мало того, этот подход ещё и не защищён от обгонов — что будет, если два разработчика начнут делать такое впараллель?

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

Это если потом в твоём стиле эти ветки всё-таки замержить между собой. Но вот именно эту глупость и не надо делать.

N>>·>strategy ours
N>>Мерж, который не мерж, только для того, чтобы потом не взрываться. Шарман, девочки.
·>Чё? Это стратегия мержа.

Дадада. Вот и получается формально мерж, по факту не мерж.

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

N>>>Вот именно что "как правило". Главное, что исключения надо потом специально обходить.
N>·>Не знаю как у вас, но обычно принято не кормить клиентов старыми багами.
N>"Учу читать. Дорого."
N>Я писал, почему там нет "старых багов". Повторяться не хочу.
Я знаю, что можно таки добиться и делать без старых багов стоя в гамаке. Но это не самый простой способ.

N>>>Если зафиксировать как ветку, то проблем сильно меньше. Кстати, именно тут и можно мержить — проблем с этим меньше.
N>·>Не понимаю что значит "зафиксировать как ветку".
N>Создать ветку с адаптацией под конкретного кастомера.
Бедный кастомер. Как он потом с этой ветки будет переходить на другие? Или у вас для каждого кастомера своя личная ветка?

N>·>Проблема не в том, что как где зафиксировать, что бы это ни значило, а в семантике нумерации версий. Если я, как пользователь, пользуюсь версией 1.2.3 и решил проапгрейдиться до 2.3.4, то я хочу быть уверенным, что у меня не вылезет тот же баг, который пофиксили в 1.2.1. Т.е., всё что было сделано в релизе 1.* должно работать в 2.*.
N>·>Вот правильно поставленный процесс мержей это обеспечивает.
N>Нет, не обеспечивает. Описанные тобой меры работают только в простейших случаях.
Просто не надо усложнять случаи. Тогда они и будут простейшие. kernel.git внезапно простейший случай.

N>Но это не главное тут:
N>·> А черри-пикинг — всё приходится делать вручную, приходится каким-то другим способом вести учёт.
N>А мержить, значит, у тебя автомат настроили. Тогда кто этому автомату объясняет, что мержить в реале, а что только формально (ours)? А конфликты тоже автомат решает?
N>Нифига себе у тебя искусственный интеллект завёлся.
Да. У меня пайплайн мержит автоматом, я же уже писал. Когда автомат не смог сработать из-за конфликта, надо мержить вручную. Это происходит редко. Я точно не считал, но по ощущениям не более чем в 5 изменений из ста.
Притом ручной мерж обычно тривиальный, т.к. он делается самим же разработчиком в тот же момент когда он запушил изменение. Он знает что и как, о чём изменение, и быстро понимает как разрешать конфликт.
Про ours я уже объяснял — это вообще редкость (не уверен, что наберётся хоть десяток за год). И решается либо предварительным явным мержем, либо ревертом.
С черрипиками беда, что это происходит когда попало и в итоге приходится разрешать конфликты спустя недели, часто кому-то другому, кто не в теме. И не приходится разбираться — незачерипикали что-то нарочно или просто забыли.

N>·>Уникальные, друг на друга непохожие в мелких деталях, трудно сравнить две, слишком много различий.
N>Нет, не создаю. И не понимаю, чем моё описание могло вызвать такие фантазии.
"ветку с адаптацией под конкретного кастомера" — это оно и есть.

N>>>1. Джиру в топку, если там сложно копаться.
N>·>Да неважно. Любую трекинговую систему или что там у вас. История кода должна храниться в графе истории, для этого предназначенным, а не где-то в стороне.
N>Не должна вся история там храниться. Код — это только код. Множество факторов, например, почему была выбрана такая архитектура и такая реализация, не могут храниться в коде.
Может, конечно. Это обычно хранят в комментах коммита (как минимум туда помещают ссылку на вики, например).

N>·>Это как раз то, на что был заточен git. Вот тут сплошные мержи из тагов (т.е. релизов). Попробуй найди черрипик.
N>Разуй глаза и посмотри не только на транковую ветку, а и на то, из чего делаются стабильные ветки ядра (даже если "ванильные").
N>Вот раз, вот два черипики, а вот оригинал. Заметь, commit id оригинала (то есть окончательно принятый в транк) попал в сообщение коммита в черипиках, то есть они были сделаны уже после высочайшего одобрения.
Я знаю что их используют. Я говорю о том, что они редки. Их кол-во по сравнению с мержами очень мало: shouldn't be *common*.

N>·>Подход с черрипиками это то что творилось во всяких svn.
N>·>Вот тут от автора: cherry-pick shouldn't be *common*.
N>А полностью прочитать сообщение не хочешь? Или это уже пошла фигурная резьба по квотингу? Весь контекст определяет только транковую разработку. И к тому же там объясняется, почему у него "the reason I ask people to not do lots of merges", что совсем не в пользу твоих подходов.
Читал я, конечно. В данном случае он говорит о So the kinds of merges I *really* dislike are the ones that are basically "let's do a regular merge every day to keep up-to-date. Мы обсуждаем мержи из релизов, вот он пишет: merge with mainline at major releases. А вот когда он рекомендует черрипикинг: cherry-picking is fine if you do it (a) fairly seldom and (b) just to small patches. Твой пример черрипикнутого коммита оно и есть. В вашем процессе черрипики такие же?

N>>>Разные версии чуть по-разному развиваются. Одна и та же функциональность как для юзера может быть реализована разным кодом в разных местах.
N>·>"чуть по разному" на языке git означает conflict resolution
N>Язык git тут ни при чём. Например, v8 делает настройку бриджа через ebtables, а v9 — через nftables. Или в v8 обмен данными на своей оболочке вокруг старого AJAX, а v9 — через React.
N>Один и тот же баг может лечиться в них заметно по-разному, мерж средствами git не поможет.
И? Разве кто-то обязует conflict resolution быть не заметно разным? Мерж поможет зафиксировать знание о том, что баг вылечился, хотя и по-разному и даже можно будет поглядеть в истории в чём эта разница собственно заключается.

N>>>·>Мерж по одному-нескольким как раз происходит по ходу пьесы, когда ты работаешь над конкретным изменением, а не через год, когда уже все всё забыли что там такое было и что с этим делать.
N>>>Ну так и черипик делается именно сразу же, а не когда забыли, зачем он был нужен.
N>·>Тогда это полный бред — зачем черрипикать, если можно замержить?
N>Зачем мудохаться с мержем, когда черипик проще, понятнее, контролируемее и надёжнее?
Напоминает риторические вопросы лет N назад. "Зачем мудохаться с X, когда Y проще, понятнее, контролируемее и надёжнее?", где (X, Y) : [(скв, rar-архивы), (cvs, svn), (svn, git), ...]

N>·>Так ничего не изменилось. Замержилось же. Ты нарисуй на бумажке граф версий и разберись какие коммиты выбираются по v1.2.3..v2.3.4.
N>OK, понял. В моём варианте такой запрос лога просто не выполнится — нет прямого пути между этими версиями. Этот путь — артефакт твоего подхода и имеет смысл только в его рамках.
Угу. И так же при твоём варианте лесом пойдёт много вкусностей типа bisect.

N>>>·>merge --strategy ours и всё: явно прописали в истории, что эти изменения не предназначены идти в старшие версии.
N>>>И так на каждое изменение. То есть тебе нужно что-то изменив в 8-й тут же примержить это в 9-ю формально, но за счёт ours реально ничего не мержить. И не забыть это сделать, потому что если не сделать, то потом оно взорвётся на следующем реальном мерже, где не будет никакого ours.
N>·>Ты вроде и так заявил "черипик делается именно сразу же". В чём разница-то? "ours" же это редкое исключение которое надо "обходить".
N>Разница в том, что черипик это явное действие: его надо сделать, чтобы получить результат. Контроль прямой и явный — не сделал, сразу видно.
N>Фиктивный мерж твоего стиля это действие, которое если не сделать, то взорвётся не сразу, а потом. Факт пропуска не очевиден, требуются специальные костыли, чтобы его обеспечивать. Мало того, этот подход ещё и не защищён от обгонов — что будет, если два разработчика начнут делать такое впараллель?
Делать что в параллель? Мержить 8->9 одновременно? Ничего не будет. Кто первый запушит, того и тапки. У второго будет пустой noop-мерж в худшем случае.
Все эти недостатки возникают в том или ином виде и с черрипиком.

N>>>>>bisect "спотыкается" ровно на том, что нужно. Если что-то сделано в этой ветке, оно и присутствует, причём в предельно явном виде — в виде конкретного коммита, отображённого диффом.
N>>>·>Каждая черрипикнутая копия коммита для git выгядит как независимый коммит и место где споткнуться.
N>>>Да, выглядит. Нет, спотыкаться не на чем.
N>·>Одно изменение — дважды, притом чуть по-разному, если были конфликты.
N>Это если потом в твоём стиле эти ветки всё-таки замержить между собой. Но вот именно эту глупость и не надо делать.
Это как? Замерженное повторно не мержится. Будет "already up-to-date".

N>·>Чё? Это стратегия мержа.
N>Дадада. Вот и получается формально мерж, по факту не мерж.
Не знаю что за факт такой.

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

N>Это универсальный метод, который используется в 100500 мест. Названия могут быть другими — например code freeze вместо красной зоны и code slush вместо жёлтой.
N>Существование отдельных фиче-веток не влияет на эту схему.

А где про это можно попкорнее прочитать?

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

N>Правильно, поэтому это надо решать принципиально иначе. Вон Gerrit ведёт отдельный change-id, который отличается от commit id, и который, в отличие от commit id, сохраняется при черипиках, при ребейзинге, при format-apply, и служит более надёжным идентификатором.

А есть сейчас какие-то аналоги gerrit'у для CR? Я с ним не работал, имеет смысл поизучать?

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

N>Подождём тогда Sharov с уточнением, что он имел в виду.

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

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

N>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
Ну да, ты не прав, ясен пень. Разница в наличии common ancestor
https://stackoverflow.com/questions/37237637/git-cherry-pick-causes-merge-conflict-while-merging-does-not

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

N>>Правильно, поэтому это надо решать принципиально иначе. Вон Gerrit ведёт отдельный change-id, который отличается от commit id, и который, в отличие от commit id, сохраняется при черипиках, при ребейзинге, при format-apply, и служит более надёжным идентификатором.

S>А есть сейчас какие-то аналоги gerrit'у для CR? Я с ним не работал, имеет смысл поизучать?

github, bitbucket и прочие — можно комментировать, можно ставить "согласен" / "не согласен", можно подключать CI.
gitlab, думаю, точно так же (не щупал ни разу).

Главное — есть заметные отличия в стиле. Gerrit не даёт возможность (или это неудобно) массово плодить всякие _именованные_ персональные фичеветки. Удобно работать с ограниченным набором целевых веток (у нас был master, а робот форкал от него всякие release90, release91...)
Временные ветки на предложения есть, но имени у них нет (можно поставить тег, но тег не уникален), только номер; получается, например, цепочка из ревью 123000, 123003, 123004... каждое надо рассмотреть и одобрить или отказать. Если все одобрены — можно отправить (какое-то ревью и всех его родителей) в целевую ветку, по их родителю видна эта ветка (соответственно master, release90 и так далее).
Зато он умеет, например, такое: сделал цепочку из 10 коммитов, в первом был заведен класс Foo. Пришёл главный ревьюер, сказал — нет, это должно быть Moo. Переименовал во всех коммитах, теперь у каждого из ревью есть patchset 1 и patchset 2. Их можно сравнить друг с другом, оно показывает даже разными цветами правки самого патчсета и правки, пришедшие из разных родителей (красный/зелёный и синий/жёлтый соответственно).
Вот тут, например, можно потыкать на публичном проекте (удобный пример, 10 выкатываний правки и цепочка коммитов это солидная история).

У github, bitbucket и прочих нет раздельного одобрямса на каждый коммит, хотя есть комментарии по строкам. Зато у них плоди именованные ветки сколько угодно, главное, не забывать их потом зачищать

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

N>>>>Вот именно что "как правило". Главное, что исключения надо потом специально обходить.
N>>·>Не знаю как у вас, но обычно принято не кормить клиентов старыми багами.
N>>"Учу читать. Дорого."
N>>Я писал, почему там нет "старых багов". Повторяться не хочу.

·>Я знаю, что можно таки добиться и делать без старых багов стоя в гамаке. Но это не самый простой способ.

Если дифф правки переносится 1:1 — всё просто и проще чем с мержем вверх.
Если нет, то в любом случае надо думать, как переносить исправление.

N>>>>Если зафиксировать как ветку, то проблем сильно меньше. Кстати, именно тут и можно мержить — проблем с этим меньше.
N>>·>Не понимаю что значит "зафиксировать как ветку".
N>>Создать ветку с адаптацией под конкретного кастомера.
·>Бедный кастомер. Как он потом с этой ветки будет переходить на другие? Или у вас для каждого кастомера своя личная ветка?

Это долго описывать, но вкратце:
1. Большинство таки сидят на стандартных ветках.
2. Если кастомер хочет какие-то особые правки себе лично, то или он сам об этом заботится (локальные патчи и сборка своими силами), или договаривается о поддержании с нашей стороны (считаем, доплачивает, но не всегда напрямую). В любом из этих двух вариантов забота мейнтейнера этих правок, что именно ему надо делать. Часто оказывается, что проблема решается в новой версии другим методом и ему уже не нужен отдельный патч на это.

N>>·>Проблема не в том, что как где зафиксировать, что бы это ни значило, а в семантике нумерации версий. Если я, как пользователь, пользуюсь версией 1.2.3 и решил проапгрейдиться до 2.3.4, то я хочу быть уверенным, что у меня не вылезет тот же баг, который пофиксили в 1.2.1. Т.е., всё что было сделано в релизе 1.* должно работать в 2.*.
N>>·>Вот правильно поставленный процесс мержей это обеспечивает.
N>>Нет, не обеспечивает. Описанные тобой меры работают только в простейших случаях.
·>Просто не надо усложнять случаи. Тогда они и будут простейшие. kernel.git внезапно простейший случай.

Ты уводишь разговор куда-то в сторону.

N>>Но это не главное тут:
N>>·> А черри-пикинг — всё приходится делать вручную, приходится каким-то другим способом вести учёт.
N>>А мержить, значит, у тебя автомат настроили. Тогда кто этому автомату объясняет, что мержить в реале, а что только формально (ours)? А конфликты тоже автомат решает?
N>>Нифига себе у тебя искусственный интеллект завёлся.
·>Да. У меня пайплайн мержит автоматом, я же уже писал.

Такой автомат не умеет решать описанный мной вопрос. Ты опять уводишь в сторону.

·>Про ours я уже объяснял — это вообще редкость (не уверен, что наберётся хоть десяток за год). И решается либо предварительным явным мержем, либо ревертом.
·>С черрипиками беда, что это происходит когда попало и в итоге приходится разрешать конфликты спустя недели, часто кому-то другому, кто не в теме. И не приходится разбираться — незачерипикали что-то нарочно или просто забыли.

Вот именно что "когда попало" не происходит. Черипики во все активные ветки, куда нужно переправлять патч, посылаются сразу при исполнении тикета. Ты себе что-то такое непонятное прифантазировал про нас и делаешь из этого кривые выводы.

N>>·>Уникальные, друг на друга непохожие в мелких деталях, трудно сравнить две, слишком много различий.
N>>Нет, не создаю. И не понимаю, чем моё описание могло вызвать такие фантазии.
·>"ветку с адаптацией под конкретного кастомера" — это оно и есть.

Нет там "слишком много различий". Опять ты что-то прифантазировал с потолка.

N>>>>1. Джиру в топку, если там сложно копаться.
N>>·>Да неважно. Любую трекинговую систему или что там у вас. История кода должна храниться в графе истории, для этого предназначенным, а не где-то в стороне.
N>>Не должна вся история там храниться. Код — это только код. Множество факторов, например, почему была выбрана такая архитектура и такая реализация, не могут храниться в коде.
·>Может, конечно. Это обычно хранят в комментах коммита (как минимум туда помещают ссылку на вики, например).

"Как минимум" там обязательная ссылка на тикет. А в тикете уже всё что нужно включая дискуссии, вики и всё такое.
В сообщение коммита добавляется, конечно, описание, почему так, но без совсем уж тотальных подробностей.

N>>Разуй глаза и посмотри не только на транковую ветку, а и на то, из чего делаются стабильные ветки ядра (даже если "ванильные").
·>Я знаю что их используют. Я говорю о том, что они редки. Их кол-во по сравнению с мержами очень мало: shouldn't be *common*.

Про "редки" твоя фантазия. Посмотри эти истории внимательно: для стабильных веток таких коммитов большинство.
Ну а для транка я никогда такой подход и не предлагал. (Хотя иногда используем ЧП в направлении более свежих веток; нетипично, но допустимо).

N>>А полностью прочитать сообщение не хочешь? Или это уже пошла фигурная резьба по квотингу? Весь контекст определяет только транковую разработку. И к тому же там объясняется, почему у него "the reason I ask people to not do lots of merges", что совсем не в пользу твоих подходов.
·>Читал я, конечно. В данном случае он говорит о So the kinds of merges I *really* dislike are the ones that are basically "let's do a regular merge every day to keep up-to-date. Мы обсуждаем мержи из релизов, вот он пишет: merge with mainline at major releases.

И всё равно это контекст транка: например, на нём сформировали и тегировали 5.10, вот в этот момент всем, кто ведёт разработку в доп. ветках, предлагают сделать merge (или rebase).

·> А вот когда он рекомендует черрипикинг: cherry-picking is fine if you do it (a) fairly seldom and (b) just to small patches. Твой пример черрипикнутого коммита оно и есть. В вашем процессе черрипики такие же?

Скорее да, если я правильно понял, о чём ты.
В момент старта подготовки, например, 90-го релиза создаётся соответствующая ветка (пусть она и называется release-90). Транк продолжает дальше расти. Если фикс бага делается на транке, ему делается ЧП в release-90, из неё в release-89 и так далее (пока не останавливаемся на ветке, развитие которой уже остановлено). На каждый момент можно сходить на внутреннюю страничку и узнать, какие релизы в каком состоянии (жёлтая зона — разработчик сам решает, уместно ли исправление, по функциональности, красная зона — надо обсуждать с QA, нет в списке — самому ничего не делать).
Можно и в обратном направлении (типа 89->90->транк) или из средней точки, но 1) надо это явно объяснять, 2) вызывает вопросы "почему так?"
В любом случае результат будет проверен собственными тестами и потом QA отделом.

N>>Один и тот же баг может лечиться в них заметно по-разному, мерж средствами git не поможет.
·>И? Разве кто-то обязует conflict resolution быть не заметно разным? Мерж поможет зафиксировать знание о том, что баг вылечился, хотя и по-разному и даже можно будет поглядеть в истории в чём эта разница собственно заключается.

ЧП даёт то же знание, что баг вылечился. Коммит с тегом тикета есть в истории, тикет содержит ссылки на исправленные ветки. Ещё и в сообщении коммита могут быть нужные слова.

N>>>>·>Мерж по одному-нескольким как раз происходит по ходу пьесы, когда ты работаешь над конкретным изменением, а не через год, когда уже все всё забыли что там такое было и что с этим делать.
N>>>>Ну так и черипик делается именно сразу же, а не когда забыли, зачем он был нужен.
N>>·>Тогда это полный бред — зачем черрипикать, если можно замержить?
N>>Зачем мудохаться с мержем, когда черипик проще, понятнее, контролируемее и надёжнее?
·>Напоминает риторические вопросы лет N назад. "Зачем мудохаться с X, когда Y проще, понятнее, контролируемее и надёжнее?", где (X, Y) : [(скв, rar-архивы), (cvs, svn), (svn, git), ...]

Ты кое-где порядок перепутал
А так — мало ли что напоминает. Обвинить в ретроградстве тривиально, сложнее — доказать обвинение. Пока что у тебя не получается: ни достаточных аргументов, ни массового опыта такого подхода. Даже в исконной обители git черипики — постоянная практика.

N>>·>Так ничего не изменилось. Замержилось же. Ты нарисуй на бумажке граф версий и разберись какие коммиты выбираются по v1.2.3..v2.3.4.
N>>OK, понял. В моём варианте такой запрос лога просто не выполнится — нет прямого пути между этими версиями. Этот путь — артефакт твоего подхода и имеет смысл только в его рамках.
·>Угу. И так же при твоём варианте лесом пойдёт много вкусностей типа bisect.

Нет, никуда bisect не уходит. Точно так же ЧП коммит будет опознаваем и бисектоспособен в истории.

N>>Разница в том, что черипик это явное действие: его надо сделать, чтобы получить результат. Контроль прямой и явный — не сделал, сразу видно.
N>>Фиктивный мерж твоего стиля это действие, которое если не сделать, то взорвётся не сразу, а потом. Факт пропуска не очевиден, требуются специальные костыли, чтобы его обеспечивать. Мало того, этот подход ещё и не защищён от обгонов — что будет, если два разработчика начнут делать такое впараллель?
·>Делать что в параллель? Мержить 8->9 одновременно? Ничего не будет. Кто первый запушит, того и тапки. У второго будет пустой noop-мерж в худшем случае.

ну ок.

·>Все эти недостатки возникают в том или ином виде и с черрипиком.

Нет, не нужно не забывать обезвреживать следующие шаги. Параллельность правки, если сами изменения не конфликтуют, пофиг (будет в целевой ветке мерж или линейная история — одинаково).

N>>>>>>bisect "спотыкается" ровно на том, что нужно. Если что-то сделано в этой ветке, оно и присутствует, причём в предельно явном виде — в виде конкретного коммита, отображённого диффом.
N>>>>·>Каждая черрипикнутая копия коммита для git выгядит как независимый коммит и место где споткнуться.
N>>>>Да, выглядит. Нет, спотыкаться не на чем.
N>>·>Одно изменение — дважды, притом чуть по-разному, если были конфликты.
N>>Это если потом в твоём стиле эти ветки всё-таки замержить между собой. Но вот именно эту глупость и не надо делать.
·>Это как? Замерженное повторно не мержится. Будет "already up-to-date".

Я про то, что конфликты пойдут только если ветки мержить целиком.

N>>·>Чё? Это стратегия мержа.
N>>Дадада. Вот и получается формально мерж, по факту не мерж.
·>Не знаю что за факт такой.

Ты ж сам через ours делаешь фиктивный мерж — второй родитель есть в истории и игнорируется по факту.

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

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

N>>Это универсальный метод, который используется в 100500 мест. Названия могут быть другими — например code freeze вместо красной зоны и code slush вместо жёлтой.
N>>Существование отдельных фиче-веток не влияет на эту схему.

S>А где про это можно попкорнее прочитать?

Супернеологизм! Спасибо, запишу.

Подробнее например здесь. В их терминах есть code slush и code freeze.
Схема слегка похожа на нашу, с отличием, что они "примораживают" транк в целом перед тем, как от него форкать релизную ветку, и аналогично ветки старших номеров перед конкретными релизами (как например для 12-й ветки перед форком 12.1, 12.2, 12.3). В это время коммит новых фич недопустим, только правки. Потом они форкают, ветки размораживаются и в них можно постить новое.
У нас такая приморозка не делается, просто по графику форкается релизная ветка (старшая или младшая) и на неё назначается полиси.

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

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

N>>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
·>Ну да, ты не прав, ясен пень. Разница в наличии common ancestor
·>https://stackoverflow.com/questions/37237637/git-cherry-pick-causes-merge-conflict-while-merging-does-not

Нафига мне вообще common ancestor? Ты вообще не понял, о чём я писал.

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

N>>Подождём тогда Sharov с уточнением, что он имел в виду.

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

Можно, не вопрос. Просто менее эффективно для общего процесса, чем из отдельной ветки. Почему — см. предыдущий комментарий.

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

N>>>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
N>·>Ну да, ты не прав, ясен пень. Разница в наличии common ancestor
N>·>https://stackoverflow.com/questions/37237637/git-cherry-pick-causes-merge-conflict-while-merging-does-not
N>Нафига мне вообще common ancestor? Ты вообще не понял, о чём я писал.
Не тебе, а алгоритму мержа. Суть в том, что при черрипиках конфликтов возникает больше и править надо вручную. Мержи чаще отрабатывают автоматически, не требуя ручного вмешательства.

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

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

N>>>>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
N>>·>Ну да, ты не прав, ясен пень. Разница в наличии common ancestor
N>>·>https://stackoverflow.com/questions/37237637/git-cherry-pick-causes-merge-conflict-while-merging-does-not
N>>Нафига мне вообще common ancestor? Ты вообще не понял, о чём я писал.
·>Не тебе, а алгоритму мержа. Суть в том, что при черрипиках конфликтов возникает больше и править надо вручную.

Не вижу причин к подобному выводу. Есть учебный пример?

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

N>>>·>https://stackoverflow.com/questions/37237637/git-cherry-pick-causes-merge-conflict-while-merging-does-not
N>>>Нафига мне вообще common ancestor? Ты вообще не понял, о чём я писал.
N>·>Не тебе, а алгоритму мержа. Суть в том, что при черрипиках конфликтов возникает больше и править надо вручную.
N>Не вижу причин к подобному выводу. Есть учебный пример?
Сходи по ссылке, там с подробным описанием как воспроизвести.

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

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

N>>>>·>https://stackoverflow.com/questions/37237637/git-cherry-pick-causes-merge-conflict-while-merging-does-not
N>>>>Нафига мне вообще common ancestor? Ты вообще не понял, о чём я писал.
N>>·>Не тебе, а алгоритму мержа. Суть в том, что при черрипиках конфликтов возникает больше и править надо вручную.
N>>Не вижу причин к подобному выводу. Есть учебный пример?
·>Сходи по ссылке, там с подробным описанием как воспроизвести.

Сходил. Повторил. Ему совершенно правильно объяснили, что он сам дурак.
`git merge other` подтягивает все коммиты 3, 4, 5 одновременно.
В случае ЧП ему надо подтянуть явно все коммиты по очереди, чтобы добиться того же, что при merge. Или, если ему нужен только пятый, да, он должен разобрать конфликт текста.
Но если в случае ЧП он может выделить только 5-й коммит, то при merge у него такой возможности нет.

Ну и что ты пытался показать этим примером, кроме банальной очевидности, что merge не выделяет один коммит из всей ветки?

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

N>·>Я знаю, что можно таки добиться и делать без старых багов стоя в гамаке. Но это не самый простой способ.
N>Если дифф правки переносится 1:1 — всё просто и проще чем с мержем вверх.
N>Если нет, то в любом случае надо думать, как переносить исправление.
Не проще. И больше шанс нарваться на необходимость ручного разрешения конфликтов.

N>·>Бедный кастомер. Как он потом с этой ветки будет переходить на другие? Или у вас для каждого кастомера своя личная ветка?
N>Это долго описывать, но вкратце:
N>1. Большинство таки сидят на стандартных ветках.
N>2. Если кастомер хочет какие-то особые правки себе лично, то или он сам об этом заботится (локальные патчи и сборка своими силами), или договаривается о поддержании с нашей стороны (считаем, доплачивает, но не всегда напрямую). В любом из этих двух вариантов забота мейнтейнера этих правок, что именно ему надо делать. Часто оказывается, что проблема решается в новой версии другим методом и ему уже не нужен отдельный патч на это.
Мерж-процесс не запрещает этого. Можно черрипикать для кастомных версий, если очень надо. Но в основном процессе это нафиг не надо и лишний усложнизм.

N>>>Нифига себе у тебя искусственный интеллект завёлся.
N>·>Да. У меня пайплайн мержит автоматом, я же уже писал.
N>Такой автомат не умеет решать описанный мной вопрос. Ты опять уводишь в сторону.
Я вроде ответил. Повторюсь другими словами. По умолчанию автомат мержит. В редких случаях, если заранее известно, что авто-мерж не нужен, то мержим желаемым образом вручную и тогда автомат ничего не делает, т.к. ветки не будут diverged, мержить банально нечего. В очень редких случаях, если выяснилось, что мерж не нужен был, можно сделать реверт.

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

N>>>Не должна вся история там храниться. Код — это только код. Множество факторов, например, почему была выбрана такая архитектура и такая реализация, не могут храниться в коде.
N>·>Может, конечно. Это обычно хранят в комментах коммита (как минимум туда помещают ссылку на вики, например).
N>"Как минимум" там обязательная ссылка на тикет. А в тикете уже всё что нужно включая дискуссии, вики и всё такое.
N>В сообщение коммита добавляется, конечно, описание, почему так, но без совсем уж тотальных подробностей.
Т.е. таки _могут_ храниться в коде. Погугли "git message best practices" или типа того. То что вы не храните — это ваша проблема.

N>>>Разуй глаза и посмотри не только на транковую ветку, а и на то, из чего делаются стабильные ветки ядра (даже если "ванильные").
N>·>Я знаю что их используют. Я говорю о том, что они редки. Их кол-во по сравнению с мержами очень мало: shouldn't be *common*.
N>Про "редки" твоя фантазия. Посмотри эти истории внимательно: для стабильных веток таких коммитов большинство.
Там большинство коммитов — мержи. Черрипики обычно для backporting — когда баг пофикшенный в последней версии очень надо запихать в предыдущую.

N>Ну а для транка я никогда такой подход и не предлагал. (Хотя иногда используем ЧП в направлении более свежих веток; нетипично, но допустимо).
Немного покопался и вот тебе ещё типичный пример: один и тот же коммит появляется в jdk-18+33 и в jdk-19+7 и т.д. Вот мерж-коммит из 18+33 в 19. Заметь как там разница merge conflict красиво рисуется. И вообще вся история как на ладони, в трекер лазить не надо.

N>И всё равно это контекст транка: например, на нём сформировали и тегировали 5.10, вот в этот момент всем, кто ведёт разработку в доп. ветках, предлагают сделать merge (или rebase).
Ок, соглашусь, тут немного не о том пишут. Поищу на досуге более релевантное. Врочем, я не вижу причин почему эти рекомендации вдруг надо менять на противоположные в немного другом контексте. Рекомендаций к твоему подходу мне видеть пока не доводилось.

N>·> А вот когда он рекомендует черрипикинг: cherry-picking is fine if you do it (a) fairly seldom and (b) just to small patches. Твой пример черрипикнутого коммита оно и есть. В вашем процессе черрипики такие же?
N>Скорее да, если я правильно понял, о чём ты.
Я о том, что черрипикать если и надо, то как можно реже и мелкие однострочные коммиты.

N>В момент старта подготовки, например, 90-го релиза создаётся соответствующая ветка (пусть она и называется release-90). Транк продолжает дальше расти. Если фикс бага делается на транке, ему делается ЧП в release-90, из неё в release-89 и так далее (пока не останавливаемся на ветке, развитие которой уже остановлено). На каждый момент можно сходить на внутреннюю страничку и узнать, какие релизы в каком состоянии (жёлтая зона — разработчик сам решает, уместно ли исправление, по функциональности, красная зона — надо обсуждать с QA, нет в списке — самому ничего не делать).
N>Можно и в обратном направлении (типа 89->90->транк) или из средней точки, но 1) надо это явно объяснять, 2) вызывает вопросы "почему так?"
N>В любом случае результат будет проверен собственными тестами и потом QA отделом.
От младших к старшим — это и есть естественное направление, DAG однако. У вас всё перевёрнуто, отсюда и мучения с черрипиками и бардак при мержах.

N>>>Один и тот же баг может лечиться в них заметно по-разному, мерж средствами git не поможет.
N>·>И? Разве кто-то обязует conflict resolution быть не заметно разным? Мерж поможет зафиксировать знание о том, что баг вылечился, хотя и по-разному и даже можно будет поглядеть в истории в чём эта разница собственно заключается.
N>ЧП даёт то же знание, что баг вылечился. Коммит с тегом тикета есть в истории, тикет содержит ссылки на исправленные ветки. Ещё и в сообщении коммита могут быть нужные слова.
Коммит не даёт. Вам даёт знание тикет, если, конечно, его правильно проапдейтили и ничего не перепутали.

N>>>>>·>Мерж по одному-нескольким как раз происходит по ходу пьесы, когда ты работаешь над конкретным изменением, а не через год, когда уже все всё забыли что там такое было и что с этим делать.
N>>>>>Ну так и черипик делается именно сразу же, а не когда забыли, зачем он был нужен.
N>>>·>Тогда это полный бред — зачем черрипикать, если можно замержить?
N>>>Зачем мудохаться с мержем, когда черипик проще, понятнее, контролируемее и надёжнее?
N>·>Напоминает риторические вопросы лет N назад. "Зачем мудохаться с X, когда Y проще, понятнее, контролируемее и надёжнее?", где (X, Y) : [(скв, rar-архивы), (cvs, svn), (svn, git), ...]
N>Ты кое-где порядок перепутал
Ну так ты же мудохаешься с мержами зачем-то. Хинт: мержами пользоваться надо, а не мудохаться с ними.

N>А так — мало ли что напоминает. Обвинить в ретроградстве тривиально, сложнее — доказать обвинение. Пока что у тебя не получается: ни достаточных аргументов, ни массового опыта такого подхода.
А ты меня тут в шарманстве обвиняешь.

N>Даже в исконной обители git черипики — постоянная практика.
Постоянная, но не для того, для чего используете вы. Вы молотком забиваете шурупы. Оно, конечно, лучше, чем гвозди отвёрткой вркучивать, но... И вы даже однажды попробовали плоской отвёрткой закрутить шуруп с крестовой шляпкой, порезались, плюнули и перешли на молоток.

N>·>Угу. И так же при твоём варианте лесом пойдёт много вкусностей типа bisect.
N>Нет, никуда bisect не уходит. Точно так же ЧП коммит будет опознаваем и бисектоспособен в истории.
Ты не понял. Баги пофиксенные в v1 не должны появляться при бисекте v1.2.3..v2.3.4, а черрипики будут.

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

N>·>Это как? Замерженное повторно не мержится. Будет "already up-to-date".
N>Я про то, что конфликты пойдут только если ветки мержить целиком.
Чтобы были конфликты, должны быть незамерженные изменения. А если мы изменения мержим, то и конфликтов не будет.

N>>>Дадада. Вот и получается формально мерж, по факту не мерж.
N>·>Не знаю что за факт такой.
N>Ты ж сам через ours делаешь фиктивный мерж — второй родитель есть в истории и игнорируется по факту.
Я не знаю что такое фиктивный мерж. Можно сссылку на доки?

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

vsb>>Каким подходом вы пользуетесь, как решаете проблемы (и считаете ли их проблемами)?
H>* внедрение изменений с родительской ветки на topic-ветку — git rebase локально.
H>* внедрение изменений с topic-ветки на родительскую — git merge --no-ff --no-squash (локально или удалённо, зависит от того, как в неё принимаются изменения) после предварительного git rebase topic-ветки.

Я не могу с topic-ветки на родительскую сделать rebase? git checkout parent, git pull; git checkout topic; git rebase parent
(или как-то так).
Что значит

после предварительного git rebase topic-ветки.

?

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

N>Ты ж сам через ours делаешь фиктивный мерж — второй родитель есть в истории и игнорируется по факту.

Я что-то упустил, но почему merge с ours фиктивный? Обычный 3-way merge, просто при конфликтах выберут нашу версию.