Здравствуйте, 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 с конфликтом это тупо отдельный коммит, никак не связанный с существующим.

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>Мерж, который не мерж, только для того, чтобы потом не взрываться. Шарман, девочки.
Чё? Это стратегия мержа.

Здравствуйте, 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>Мерж, который не мерж, только для того, чтобы потом не взрываться. Шарман, девочки.
Чё? Это стратегия мержа.