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

N>>·>Я знаю, что можно таки добиться и делать без старых багов стоя в гамаке. Но это не самый простой способ.
N>>Если дифф правки переносится 1:1 — всё просто и проще чем с мержем вверх.
N>>Если нет, то в любом случае надо думать, как переносить исправление.
·>Не проще. И больше шанс нарваться на необходимость ручного разрешения конфликтов.

Если это то что ты писал в предыдущем сообщении, то это ерунда

Автор: netch80
Дата: 23.02.22

не имеющая отношения к реальности.

N>>>>Нифига себе у тебя искусственный интеллект завёлся.
N>>·>Да. У меня пайплайн мержит автоматом, я же уже писал.
N>>Такой автомат не умеет решать описанный мной вопрос. Ты опять уводишь в сторону.
·>Я вроде ответил. Повторюсь другими словами. По умолчанию автомат мержит. В редких случаях, если заранее известно, что авто-мерж не нужен, то мержим желаемым образом вручную и тогда автомат ничего не делает, т.к. ветки не будут diverged, мержить банально нечего. В очень редких случаях, если выяснилось, что мерж не нужен был, можно сделать реверт.

Реверт мержа? Ещё один усложнизм на ровном месте.

N>>·>Про ours я уже объяснял — это вообще редкость (не уверен, что наберётся хоть десяток за год). И решается либо предварительным явным мержем, либо ревертом.
N>>·>С черрипиками беда, что это происходит когда попало и в итоге приходится разрешать конфликты спустя недели, часто кому-то другому, кто не в теме. И не приходится разбираться — незачерипикали что-то нарочно или просто забыли.
N>>Вот именно что "когда попало" не происходит. Черипики во все активные ветки, куда нужно переправлять патч, посылаются сразу при исполнении тикета. Ты себе что-то такое непонятное прифантазировал про нас и делаешь из этого кривые выводы.
·>Автоматом? Как контролировать что ничего не забыли?

Человеком. Он выбирает, какие коммиты куда должны пойти. Ревьюеры проверяют комплектность со своей точки зрения. Часто оказывается, что для другой ветки что-то надо убрать, что-то добавить.
Финальную точку ставят тесты.
Но сделать ЧП на всю цепочку — для простого случая — это банальное действие.

N>>>>Не должна вся история там храниться. Код — это только код. Множество факторов, например, почему была выбрана такая архитектура и такая реализация, не могут храниться в коде.
N>>·>Может, конечно. Это обычно хранят в комментах коммита (как минимум туда помещают ссылку на вики, например).
N>>"Как минимум" там обязательная ссылка на тикет. А в тикете уже всё что нужно включая дискуссии, вики и всё такое.
N>>В сообщение коммита добавляется, конечно, описание, почему так, но без совсем уж тотальных подробностей.
·>Т.е. таки _могут_ храниться в коде. Погугли "git message best practices" или типа того. То что вы не храните — это ваша проблема.

Спасибо, с практиками знакомы. Но заменять сообщениями коммита всю ту информацию, что может быть в тикете, некорректно — там может быть тонна pdf'ок, логи, и много подобного.
Ты впал в режим Адмирала Ясен Хер и не просто думаешь, что ты главный кэп на форуме, а ещё и активно это пропагандируешь. Это тупо смешно.

·>Там большинство коммитов — мержи. Черрипики обычно для backporting — когда баг пофикшенный в последней версии очень надо запихать в предыдущую.

Именно.

N>>Ну а для транка я никогда такой подход и не предлагал. (Хотя иногда используем ЧП в направлении более свежих веток; нетипично, но допустимо).
·>Немного покопался и вот тебе ещё типичный пример: один и тот же коммит появляется в jdk-18+33 и в jdk-19+7 и т.д. Вот мерж-коммит из 18+33 в 19. Заметь как там разница merge conflict красиво рисуется. И вообще вся история как на ладони, в трекер лазить не надо.

OK, есть публичный пример, как люди работают в этой схеме.

N>>И всё равно это контекст транка: например, на нём сформировали и тегировали 5.10, вот в этот момент всем, кто ведёт разработку в доп. ветках, предлагают сделать merge (или rebase).
·>Ок, соглашусь, тут немного не о том пишут. Поищу на досуге более релевантное. Врочем, я не вижу причин почему эти рекомендации вдруг надо менять на противоположные в немного другом контексте. Рекомендаций к твоему подходу мне видеть пока не доводилось.

Значит, игнорировал в упор. Потому что их много.

·>От младших к старшим — это и есть естественное направление, DAG однако. У вас всё перевёрнуто, отсюда и мучения с черрипиками и бардак при мержах.

Про мучения ты себе что-то нафантазировал.
Бардак при мержах был бы, если бы мы использовали твой подход с мержами. Но нет такого подхода — нет и бардака

Но я запомню как странный вариант.

N>>ЧП даёт то же знание, что баг вылечился. Коммит с тегом тикета есть в истории, тикет содержит ссылки на исправленные ветки. Ещё и в сообщении коммита могут быть нужные слова.
·>Коммит не даёт. Вам даёт знание тикет, если, конечно, его правильно проапдейтили и ничего не перепутали.

В коммите есть базовое описание. Если его недостаточно, идём к тикету. Но такие ситуации встречаются уже когда требуется что-то более глубокое, чем просто анализ "когда это возникло", и тогда оно 100% требует анализа контекста, предусловий и т.п.

·>Ну так ты же мудохаешься с мержами зачем-то. Хинт: мержами пользоваться надо, а не мудохаться с ними.

Вот как раз не пользуемся — и поэтому не мудохаемся

N>>А так — мало ли что напоминает. Обвинить в ретроградстве тривиально, сложнее — доказать обвинение. Пока что у тебя не получается: ни достаточных аргументов, ни массового опыта такого подхода.
·>А ты меня тут в шарманстве обвиняешь.

???

N>>Даже в исконной обители git черипики — постоянная практика.
·>Постоянная, но не для того, для чего используете вы. Вы молотком забиваете шурупы. Оно, конечно, лучше, чем гвозди отвёрткой вркучивать, но... И вы даже однажды попробовали плоской отвёрткой закрутить шуруп с крестовой шляпкой, порезались, плюнули и перешли на молоток.

Плохая аналогия подобна котёнку с дверцей. Ещё и неадекватная.

N>>·>Угу. И так же при твоём варианте лесом пойдёт много вкусностей типа bisect.
N>>Нет, никуда bisect не уходит. Точно так же ЧП коммит будет опознаваем и бисектоспособен в истории.
·>Ты не понял. Баги пофиксенные в v1 не должны появляться при бисекте v1.2.3..v2.3.4, а черрипики будут.

Не будут. Потому что такого бисекта просто не будет. Он не адекватен и не нужен.

N>>>>Дадада. Вот и получается формально мерж, по факту не мерж.
N>>·>Не знаю что за факт такой.
N>>Ты ж сам через ours делаешь фиктивный мерж — второй родитель есть в истории и игнорируется по факту.
·>Я не знаю что такое фиктивный мерж. Можно сссылку на доки?

Это то, что ты делаешь с ключом ours. Одна сторона формально присутствует, по факту игнорируется.