Как настроить git merge / git pull для файлов xml?
У меня такая ситуация:
Исходный файл test.xml:
<li>
<span>BA</span>
</li>
Файл с зафиксированными локальными изменениями:
<li>
<span>BA</span>
</li>
<li>
<span>CE</span>
</li>
Файл с удаленными изменениями, полученными через git pull:
<li>
<span>BA</span>
</li>
<li>
<span>DF</span>
</li>
git pull идентифицирует только строки с новыми <span> как изменения, есть ли какой-либо вариант для использования с git pull / git merge, который может избежать этой ситуации?
ОБНОВИТЬ: Это файл, в котором обнаружен конфликт:
<li>
<span>BA</span>
</li>
<li>
<<<<<<< HEAD
<span>CE</span>
=======
<span>DF</span>
>>>>>>> master
</li>
Пока я ожидал чего-то вроде:
<li>
<span>BA</span>
</li>
<li>
<<<<<<< HEAD
<li>
<span>CE</span>
</li>
=======
<li>
<span>DF</span>
</li>
>>>>>>> master
</li>
Я пробовал аргумент --strategy-option=patience на git pull, но он вообще не дал никакого эффекта.
Это всего лишь простой пример. На самом деле эта проблема возникает с файлами .resx, которые редактируются с помощью редактора Visual Studio по умолчанию.
@ eftshift0 Да! Это то, что я ожидал, но на самом деле git определяет только <span> CE </span> как конфликт.
Можете ли вы показать нам (добавить это к вопросу), какой git показывает вам как конфликт?
@ eftshift0 Конечно! Добавил файл с конфликтами.
Git понимает, что строки открытия / закрытия <li> </li> одинаковы в обеих ветвях, поэтому он говорит что-то вроде: Хорошо ... эта часть изменений между обеими ветвями одинакова, поэтому не буду жаловаться на это это то, что, я думаю, хотели бы получить разработчики.
Правильно @ eftshift0, вот в чем суть, но на самом деле у меня возникает эта проблема с файлами resx, и они редактируются с помощью инструмента, который я могу настроить для редактирования xml таким образом, чтобы избежать этих конфликтов. Итак, вопрос в том, как я могу настроить git для использования какого-то пессимистического алгоритма, который не принимает эти строки (<li>) из разных веток / коммитов как эквивалентные.
Изменение merge.conflictstyle на diff3 вызвало в качестве побочного эффекта работу git, как и ожидалось. Но почему?
Установка для merge.conflictStyle значения diff3 указывает Git записывать базовый текст слияния в рабочее дерево вместе с версиями этапа 2 и этапа 3 внутри области маркера конфликта. Другого эффекта он не имеет, и если вы напишете собственный драйвер слияния, это не имеет значения. Правильный способ сделать это - использовать настраиваемый драйвер слияния, но написать правильный настраиваемый драйвер слияния для XML чрезвычайно сложно.
@torek, это то, что после merge.conflictStyle конфликтная область включала <li>, как и ожидалось. Нет абсолютно ничего о том, чтобы писать собственные драйверы слияния или что-то в этом роде.
@AdilsondeAlmeidaJr: Ага, поэкспериментировав, я понял, что вы имеете в виду. Однако в комментариях нет места для форматирования, необходимого для его правильного описания. Думаю добавлю ответ в связанный дубликат.
Что бы вы хотели посмотреть? Потому что из того, что я могу понять, конфликт должен иметь место только для последних 3 строк, потому что первые три строки не были изменены ни в одной из двух ветвей, поэтому ...