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

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 делаешь фиктивный мерж — второй родитель есть в истории и игнорируется по факту.