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

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

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

не имеющая отношения к реальности.
Да, действительно... извиняюсь. Пытаюсь быстренько нагуглить и натыкаюсь не на то. Вот тут есть чтиво про common ancestor и recursive merge: https://devblogs.microsoft.com/oldnewthing/20180315-00/?p=98245

N>>>Такой автомат не умеет решать описанный мной вопрос. Ты опять уводишь в сторону.
N>·>Я вроде ответил. Повторюсь другими словами. По умолчанию автомат мержит. В редких случаях, если заранее известно, что авто-мерж не нужен, то мержим желаемым образом вручную и тогда автомат ничего не делает, т.к. ветки не будут diverged, мержить банально нечего. В очень редких случаях, если выяснилось, что мерж не нужен был, можно сделать реверт.
N>Реверт мержа? Ещё один усложнизм на ровном месте.
Эээ? Что в этом сложного? Одна команда, не сложнее черрипика. А с учётом того, что на автоматизация заменяет сотни ручных черрипиков то один-два реверта ну никак на усложним не тянут. Или ты тоже панически боишься ревертов?

N>>>Вот именно что "когда попало" не происходит. Черипики во все активные ветки, куда нужно переправлять патч, посылаются сразу при исполнении тикета. Ты себе что-то такое непонятное прифантазировал про нас и делаешь из этого кривые выводы.
N>·>Автоматом? Как контролировать что ничего не забыли?
N>Человеком. Он выбирает, какие коммиты куда должны пойти. Ревьюеры проверяют комплектность со своей точки зрения. Часто оказывается, что для другой ветки что-то надо убрать, что-то добавить.
N>Финальную точку ставят тесты.
N>Но сделать ЧП на всю цепочку — для простого случая — это банальное действие.
Т.е. контроля нет. Вся надежда на внимательность человека.

N>·>Т.е. таки _могут_ храниться в коде. Погугли "git message best practices" или типа того. То что вы не храните — это ваша проблема.
N>Спасибо, с практиками знакомы. Но заменять сообщениями коммита всю ту информацию, что может быть в тикете, некорректно — там может быть тонна pdf'ок, логи, и много подобного.
N>Ты впал в режим Адмирала Ясен Хер и не просто думаешь, что ты главный кэп на форуме, а ещё и активно это пропагандируешь. Это тупо смешно.
Ты заявил глупую вещь, что "не могут храниться в коде", вот и пришлось покапинанствовать. Более того, при желании pdf-и и логи тоже можно класть в репу в виде git notes.

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

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

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

N>·>От младших к старшим — это и есть естественное направление, DAG однако. У вас всё перевёрнуто, отсюда и мучения с черрипиками и бардак при мержах.
N>Про мучения ты себе что-то нафантазировал.
N>Бардак при мержах был бы, если бы мы использовали твой подход с мержами. Но нет такого подхода — нет и бардака
Ага. В мелком тривиальном проекте типа jdk оно может и сработает, а в вашем исключительном проекте другие законы природы.

N>Но я запомню как странный вариант.
Да, запомните этот твит!

N>>>ЧП даёт то же знание, что баг вылечился. Коммит с тегом тикета есть в истории, тикет содержит ссылки на исправленные ветки. Ещё и в сообщении коммита могут быть нужные слова.
N>·>Коммит не даёт. Вам даёт знание тикет, если, конечно, его правильно проапдейтили и ничего не перепутали.
N>В коммите есть базовое описание. Если его недостаточно, идём к тикету. Но такие ситуации встречаются уже когда требуется что-то более глубокое, чем просто анализ "когда это возникло", и тогда оно 100% требует анализа контекста, предусловий и т.п.
Я не про описание коммита, а про положение коммита в графе истории.

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

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

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

N>·>Ты не понял. Баги пофиксенные в v1 не должны появляться при бисекте v1.2.3..v2.3.4, а черрипики будут.
N>Не будут. Потому что такого бисекта просто не будет. Он не адекватен и не нужен.
Почему? Это какой-то закон природы? Чем ваш релиз 89 с десятком патчей так принципиально полностью отличается от релиза 90 с патчами? Неужели вы проект уже 90 раз с нуля переписывали?!!

N>·>Я не знаю что такое фиктивный мерж. Можно сссылку на доки?
N>Это то, что ты делаешь с ключом ours. Одна сторона формально присутствует, по факту игнорируется.
Я не знаю что это значит. Ну допустим ты наклеил ярлык "фиктивный". И? Ты говоришь как будто это что-то плохое.