Этот комментарий был интересной иллюстрацией того, как может произойти "злое" слияние:
Иногда минимальное ручное разрешение приводит к появлению строк, которых не было.
Например.
- '
ours' изменяет имя функции,
- '
theirs' изменяет возвращаемое значение,
- нам нужен метод с новым именем и новым возвращаемым значением).
Это злой? IOW: иногда необходимы злые слияния
Обратите внимание, что эта статья упоминает "злые слияния" в другом контексте (непреднамеренные слияния) и выступает за постоянный отказ, а не слияние ... но что игнорирует опасность git pull --rebase.
Junio C Hamano, главный сопровождающий git, точнее в своем апрельском блоге 2013 :
Каноническим примером того, как «злое слияние» происходит в реальной жизни (и это хорошо), является приспособление к семантическим конфликтам. Это почти никогда не имеет ничего общего с текстовыми конфликтами.
(обычно это изменение API, например: вы добавляете параметр, в то время как другой разработчик добавляет вызов этой функции ... но без никаких дополнительных параметров)
Это означает, что вы должны исправить семантический конфликт (например, отсутствующий аргумент для функции, которая теперь его принимает) во время слияния, что означает создание строки, которая:
- не существует в вашем коде (где вы правильно сделали изменения API)
- не существует в удаленной ветви, которую вы сейчас объединяете (где другой разработчик не знал об изменении API)
Это делает слияние "злым слиянием" .
При "git log -c/--cc", такая строка будет отображаться с двойным плюсом в выводе многоканального патча, чтобы показать, что " этого не было в любой родитель".
Из git log справочная страница :
Различное форматирование
-c::
С помощью этой опции вывод diff для фиксации слияния показывает различия между каждым из родителей к результату слияния одновременно, вместо того, чтобы показывать попарно diff между родителем и результатом по одному.
Кроме того, в нем перечислены только файлы, которые были изменены от всех родителей.