0

I have the following situation:

Original test.xml file:

<li>
  <span>BA</span>
</li>

File with committed local changes:

<li>
  <span>BA</span>
</li>
<li>
  <span>CE</span>
</li>

File with remote changes received through git pull:

<li>
  <span>BA</span>
</li>
<li>
  <span>DF</span>
</li>

git pull is identifying only the lines with the new <span>s as changes, is there any option to use with git pull / git merge which can avoid this situation?

UPDATE: This is the file with the conflict as it is detected:

<li>
  <span>BA</span>
</li>
<li>
<<<<<<< HEAD
  <span>CE</span>
=======
  <span>DF</span>
>>>>>>> master
</li>

While I was expecting something like:

<li>
  <span>BA</span>
</li>
<li>
<<<<<<< HEAD
<li>
  <span>CE</span>
</li>
=======
<li>
  <span>DF</span>
</li>
>>>>>>> master
</li>

I´ve tried the --strategy-option=patience argument on git pull but it doesn´t any effect at all.

This is only a simple example. Actually this problem is happening with .resx files which are edited through the default visual studio editor.

Adilson de Almeida Jr
  • 2,761
  • 21
  • 37
  • 1
    What would you like to see? Because from what I can gather, the conflict has to be there only for the last 3 lines because the first three lines were not modified on either of the 2 branches so..... – eftshift0 Dec 17 '18 at 19:58
  • @eftshift0 Yes! That´s what I expected, but actually git identifies only the CE as a conflict. – Adilson de Almeida Jr Dec 17 '18 at 20:25
  • Can you show us (add it to the question) what git is showing you as the conflict? – eftshift0 Dec 17 '18 at 20:35
  • @eftshift0 Sure! Added the file with the conflicts. – Adilson de Almeida Jr Dec 17 '18 at 21:03
  • Git is realizing that the opening/closing
  • lines are the same on both branches so it's saying something like: Ok... this part of the change between both branches is the same so won't complain about it which is what I would think developers would like to get. – eftshift0 Dec 17 '18 at 21:05
  • Right @eftshift0, that is the point, but actually I m getting this problem on resx files, and these are edited with a tool I can config to edit the xml in a way I avoid that conflicts. So the point is, how could I setup git to use some kind of pessimistic algorithm that don´t assume those lines (
  • ) from different branches/commits as equivalent.
    • – Adilson de Almeida Jr Dec 17 '18 at 21:38
  • Changing merge.conflictstyle to diff3 caused as a side effect the git work as expected. But, why? – Adilson de Almeida Jr Dec 17 '18 at 22:57
  • Setting `merge.conflictStyle` to `diff3` tells Git to write the merge-base text into the work-tree, along with the stage 2 and stage 3 versions, inside the conflict marker region. It has no other effect, and if you write a custom merge driver, it's irrelevant. The right way to do this is with a custom merge driver, but writing a correct custom merge driver for XML is extraordinarily difficult. – torek Dec 17 '18 at 23:23
  • @torek, this is the point, after `merge.conflictStyle`, the conflict region included the `
  • `s as expected. There is absolutely nothing about write custom merge drivers or something like.
    • – Adilson de Almeida Jr Dec 18 '18 at 16:25