1

When I try to merge stage into master I get these weirdly nested conflict lines. As I try to pick the one I want to keep in vimdiff mergetool with :diffg LO and :diffg RE it does seemingly weird changes and I can never get to a proper merge resolution.

The screenshots are from Notepad++ compare plugin. Local file on left, Remote one on right.

Conflict 1:

  • The lines I actually want to keep are just the two divs on the left side which aren't marked as different between the files by Notepad++
  • http://puu.sh/ntjfu/ffe8d95ed4.png

Conflict 2:

My guess is that the merge marks are causing conflicts with other merge marks, putting merge marks around them. When, say, a remote change is chosen, the next merge marks that were actually the conflict now are interpreted as actual merge marks, but it doesn't pick up the right opening or closing lines of the merge mark due to how they are nested.

I've tried simply deleting all the merge stuff (the merge marks and their presented lines, .orig.orig and _LO and _RE files that appeared) and leave the files (the real file and .orig file) the way I want them, but that didn't work for me.

Can you please explain how these kind of conflicts work, how should I see them and what are the options for dealing with them?

Also, to understand merging better, I'd like to know how Git finds those marks. From what I tried, I'm thinking it will look for them based on a record of their location and run into problems if they have been deleted entirely from where they should be?

a_rts
  • 319
  • 2
  • 13
  • I'd still like to get some answers to my questions, but in case anyone has this issue, I managed to sort of resolve it by doing "git rm path/to/file.phtml.orig path/to/other/file.phtml.orig" to remove both files from git and then I was able to finish the merge with git commit. – a_rts Mar 04 '16 at 11:14
  • the image links have rot. Never use external image links like that, because they can die anytime, rendering your post invalid. [Any texts like code/data/errors must be posted as text](https://meta.stackoverflow.com/q/285551/995714). For things that really need to be posted as images, always use the internal image uploader of stackoverflow, which uses a special imgur license that never expires – phuclv Oct 07 '22 at 08:21

2 Answers2

0

My guess as to why you have "nested" conflicts is because you had left a conflict "hanging" (as in "unresolved" yet committed) in one of the branches you are trying to merge and now that you are trying to merge "again" you are seeing the previous conflict show up now as part of another merge. Can you check the content of those file on the revisions you are trying to merge and tell us if that's indeed the case?

eftshift0
  • 26,375
  • 3
  • 36
  • 60
0

weirdly nested conflict lines.

My guess is that the merge marks are causing conflicts with other merge marks, putting merge marks around them

git rerere usually helps record and reuse conflict merges, but would fail here when considering nested merge conflict.

But Git 2.20 (Q4 2018) will add fixes to "git rerere" corner cases, especially when conflict markers cannot be parsed in the file.

See commit bd7dfa5, commit 4af3220, commit 5ebbdad, commit c0f16f8, commit 221444f, commit 93406a2, commit fb90dca, commit 2373b65 (05 Aug 2018), and commit 28fc9ab, commit c5d1d13, commit e69db0b (14 Jul 2018) by Thomas Gummerer (tgummerer).
(Merged by Junio C Hamano -- gitster -- in commit 3900689, 17 Sep 2018)

rerere: teach rerere to handle nested conflicts

Currently rerere can't handle nested conflicts and will error out when it encounters such conflicts.
Do that by recursively calling the 'handle_conflict' function to normalize the conflict.

Note that a conflict like this would only be produced if a user commits a file with conflict markers, and gets a conflict including that in a susbsequent operation.

The conflict ID calculation here deserves some explanation:

As we are using the same handle_conflict function, the nested conflict is normalized the same way as for non-nested conflicts, which means the ancestor in the diff3 case is stripped out, and the parts of the conflict are ordered alphabetically.

The conflict ID is however is only calculated in the top level handle_conflict call, so it will include the markers that 'rerere' adds to the output.
E.g. say there's the following conflict:

<<<<<<< HEAD
1
=======
<<<<<<< HEAD
3
=======
2
`>>>>>>> branch-2
`>>>>>>> branch-3~

it would be recorded as follows in the preimage:

<<<<<<<
1
=======
<<<<<<<
2
=======
3
.>>>>>>>
.>>>>>>>

and the conflict ID would be calculated as

sha1(1<NUL><<<<<<<
2
=======
3
.>>>>>>><NUL>)`

(The . are just here to avoid markdown interpretation: this should read >>>>>>>)

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250