Git стратегии слияния: пробелы делают умолчание не конфликтуют и приносят неожиданные результаты

После многих испытаний я получил этот простой сценарий:

a --> b --> c --   (master)
 \              \
  --> d --> b' --> e   (branch)

Где:

b' - это вишневый выбор b
e - это слияние из master.

b' было выполнено после c и c имеет модификации для тех же файлов, что и b (d, вероятно, не имеет значения).

e может выглядеть очень неожиданно.

Пусть говорят, что все они имеют дело с одним и тем же файлом foobar.txt ". Так выглядит файл в каждой фиксации:

// ----------- a
foo

delme

bar

// ----------- b
foo

delme

new

bar

// ----------- c
foo

new

bar

// ----------- b'
foo

delme

new

bar

// ------------ e
foo

new

new

bar

Теперь это было из моего краткого теста только сейчас, с этой точной настройкой.

Если вы удалите все пробелы, такой проблемы нет. Как я и ожидал, слияние просто обвинит в конфликте. Но я не думаю, что использование какого-либо параметра -X для пробелов - это то, что мы ищем здесь... Или это?

Между тем, по моему производственному коду, из-за которого я начал исследовать все это и у которого не было почти столько пробелов, я увидел, что e выглядит примерно так:

// ----------- e
foo

delme

new

bar

Все, что происходит при слиянии , никогда не обвиняет какой-либо конфликт!

Если git должен был совершить какое-либо магическое автоматическое слияние вуду, вот что я ожидаю, что он будет выглядеть следующим образом:

// ----------- e
foo

new

bar

Но этого также не бывает.

Как немного отказ от ответственности...

Я также попробовал прочитать руководство f, но я не могу понять слишком много пунктов в рамках стратегий слияния. Кроме того, на самом деле не сказано, что делает стратегия resolve под капотом, например:

Он пытается тщательно определить неоднозначность скрещивания слияния и считается в целом безопасным и быстрым.

Это ничего не говорит.

Текст о стандартном recursive больше, но я также не смог извлечь из него достаточно информации:

Сообщалось, что это привело к меньшему количеству конфликтов слияния, не вызывая ошибок при выполнении тестов, выполненных при фактических компиляции, взятых из истории разработки ядра Linux 2.6.

Зафиксирован? Итак, мы получили 1 очень тяжелый unit test и предположили, что несколько отчетов все в порядке?

Ну, это слишком расплывчато для меня.

Я думаю, что я должен делать что-то неправильно! Итак, как я могу сделать это правильно?

Что мне нужно, чтобы вернуться к слиянию без каких-либо забот?

Ответ 1

Основная проблема заключается в том, что нет формальной модели для того, что означает правильные автоматические слияния, которые делают правильные вещи в каждом случае. На самом деле "правильная вещь" может различаться для разных вариантов использования способами, о которых алгоритм слияния не имеет понятия. Были предприняты различные попытки создать единый правильный алгоритм слияния, который всегда делает правильные вещи (различные стратегии объединения монотонов, Codeville, Precise Codeville, Darcs и т.д.), И все они каким-то образом в реальных случаях.

Итак, для алгоритма слияния в реальном мире "он отлично работает на реальной кодовой базе с большим количеством слияний" - это самое лучшее, что вы сможете сделать. Это означает, что вы никогда не должны слепо доверять результатам чистого автоматического слияния; в то время как он может быть полностью слит без конфликтов, возможно, он не сделал то, что вы ожидали. Вам все равно нужно просмотреть, что сделал слияние, и проверить результат.

Мой общий подход состоит в том, чтобы попробовать несколько различных параметров слияния, как и вы, чтобы убедиться, что один из них производит правильное слияние. Если это не сработает, чтобы получить правильное слияние (или слияние, которое создает соответствующий конфликт, который вы можете разрешить), тогда вы должны сделать git merge --no-commit и исправить слияние, если это необходимо, прежде чем совершать его.