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