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