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

N>·>Не знаком я с этим товарищем.
N>Ну тогда просто знай, что переход BIND 8 -> 9 был сделан через написание кода с нуля. Вся старая история не была продолжена.
Бывает. Такая ситуация будет отражена в графе истории, что истории независимы и у них нет общей базы. Но причём обсуждаемый тут cherry-pick vs merge? Поможет ли gerrit? Или ты просто за жизнь рассуждаешь?

N>>>Но даже если без такого радикализма, 8-я версия, очень вероятно, будет сделана на релизной ветке, а не на транке (вообще не представляю себе, кто будет её делать на транке). И там может быть всё заметно иначе.
N>·>Шо? Не понял. Когда писали 8ю версию, она была транком.
N>Когда вводили принципиально новое — да. Когда релизили и патчили — уже нет.
Если патчили изначально бардаком, накатывая разные изменения в разные точки истории, то да — в хаосе не разобраться. С черрипиками будет вообще беда.

N>·>diverged branch. Если в 17 всегда мержить 8, то 17 не будет diverged от 8 и мержи упрощаются.
N>Нет, не упрощаются. Часть правок от 8 не нужна, часть слишком сложно мержить из-за изменения стиля, расположения по файлам и всё такое, часть реализуется совсем иначе.
Ну и? Чем поможет cherry-pick? Вот merge помочь может — git может детектить перемещение расположения по файлам. А если ещё и rerere включить...

N>>>·>Для удобства. Если граф истории отражает реальный процесс разработки — это хороший граф.
N>>>Он и отображает. Безо всякого форсирования на возможность мержа заметно разных веток.
N>·>Нет. Замерженный коммит появляется в обоих ветках. Зачерипиканный — это два независимых коммита с т.з. графа истории.
N>Правильно, поэтому это надо решать принципиально иначе. Вон Gerrit ведёт отдельный change-id, который отличается от commit id, и который, в отличие от commit id, сохраняется при черипиках, при ребейзинге, при format-apply, и служит более надёжным идентификатором.
Да. Мне тоже подход gerrit нравится. Но это всё-таки заточено на PR процесс, а не на мерж между разными ветками.

N>Можно было вместо этого просто генерировать uuid на коммит, но их метод чуть надёжнее.
В gerrit это и делают — хуком генерят дополнительный uuid в коммит.

N>Ещё работает связь по id тикета, который тоже должен быть в сообщении коммита.
N>А сложные случаи всё равно требуют анализа задачи.
Во-во.

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

N>>>Из них делаются спецификации, из них тикеты с задачами и только из них — код. Он тут вообще "четвертичен", если не дальше.
N>>>Клиентам отправляется продукт, а не "код из СКВ".
N>·>Продукт-то из чего собирается? Из тикетов?
N>И на что тут влияет, из чего собирается продукт?
С т.з. разработчика — результат работы — коммиты. И разбираться в графе истории проще, чем в тикетах, особенно если о виде графа заботятся, а не пихают всё что пихается.

N>Я ничего не утрирую, всё на опыте. Вариант с мержем из предыдущих веток приводит к резкому усложнению сопровождения кода. В истории тупо мусор.
Можно какие-нибудь детали? Пример?