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

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

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