I've had a strange situation where a git merge does not correctly identify all merge conflicts in a file.
If I use a
, b
, c
, etc. to represent blocks of code (which in reality are 100s/1000s of lines of XML), the following happens:
Original Branched Master File
a
b
c
d
e
Altered File on Feature1 Branch
g
b
c
h
i
d
j
Altered File on Master
a
b
f
d
e
So if I merge master
into feature1
I should get the following conflicted file
g
b
<<<<<<< HEAD
c
h
i
=======
f
>>>>>>> master
d
j
(and I tested this using files as above, rather than the actual ones, where I do get the correct conflicted file)
But what I actually get with the real files is effectively
g
b
c
<<<<<<< HEAD
h
i
=======
f
>>>>>>> master
d
j
That is, it thinks blocks h
/i
and f
are in conflict, when actually block f
is what replaced block c
in master
.
Is there any reason why git should mess up like this? I have triple-checked and I'm 99.9% sure that the representation here is accurate.