Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.102.1
• OS Version: Windows 11 Enterprise 10.0.22631

Steps to Reproduce:

1. Check out the repository from https://github.com/Andree2/GitMerge250
2. In Visual Studio Code, merge branchB to main
3. The merge operation detects conflicts both in modification.txt and rename.txt
4. The conflicts in modification.txt are recognized by vscode and can be resolved there
5. Bug:
   • Though rename.txt is marked as having conflicts, vscode cannot display the conflict, although git conflict markers are present in the file
   • When accepting either current or incoming as conflict resolution, vscode resolves the conflict, but the git conflict markers stay in the resolved file

Notes:

This seems to be caused by nature of the merge operation is the example. The branch topology is:

    C2          branchA
  /    \
C1 ---------    main
  \        /
   C3 ----      branchB

branchA renames the file rename.txt in commit C2, branchB renames the same file in commit C3. branchA has then been merged back to main. When trying to merge branchB back to main, the problem described above appears.

In this scenario, the git conflict markers (<<<<<<<<, ========, >>>>>>>>) are each 8 characters long, as they are extended by git. Normally this is to track a recursive merge. In the example above, there does not seem to be a recursive merge, but with the git ORT merge engine, certain scenarios seems to start out one character longer than with older git versions (before 2.23).

For other (simpler) conflicts, they are only 7 characters long (which is the default). It appears that vscode does not handle these 8-length conflict markers correctly. When manually shortening the conflict markers to 7 characters, vscode correctly displays the conflict.