Change:
Issue Type: <bBug</bOpen add/add conflict file. ! ! Neither is terribly useful, frankly. VS Code version: Code - Insiders 1.69.0-insider (, 2022-06-29T05:20:28.364Z) OS version: WindowsNT x64 6.1.7601 Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Open add/add conflict file. From the SCM viewlet? Sure you did that?
Sure. Fresh/pure Insiders build. Git repo. The only two settings I have changed are location and that flag.
I saw this too, but it was fixed when I removed my setting from .
I understand vscode can be used as a difftool for git with is there a similar command like yet?
How's that in any way related to VS Code?…
Did as you suggested, no change. Any other ideas? Perhaps, I'm not understanding something. What are the steps to open the interface which is seen in the release notes? Assuming I have fresh Insiders build and clean profile.
Please describe in detailed steps what you are doing. The sequence should be like enable merge editor via setting have GIT report a file as being conflicted (note that is different from a file just containing merge marker, run and check that it says "You have unmerged paths.") in the SCM view select the item merge editor shows
I'm doing literally what I said. VS Code. git.mergeEditor merge conflict. the conflicted file. From SCM view. Yes,
can you provide a recording?
I'm also suffering from this issue after updating to the latest stable release (v1.69).
Same here. Works on some files but on others.
Have the problem, i have updated VSCode as well. Also enabled "git.experimental.mergeEditor": true, in !
That's the wrong setting. It is now
It is still the same, even after updating to
I'm not sure if this is the same issue as the previous git status output looked more like being in a usual merge state but maybe this still helps. For me this happens during rebase. It works for the first file (sometimes?) and logs the following for the following files: In case of a rebase should be used instead of I think.
Thanks - finally somebody checking the logs
There is actually two issues. For once we don't read but always assume . That is unhappy but only affects labels and doesn't prevent the editor from opening. The next error is more interesting: this would mean that we fail to read the conflicting file. Assuming I know nothing about your setup (and little about git) can you provide steps that got you here? I assume you rebased but do you have more details or a git repo to share in which I can reproduce this?
Not sure actually. Just created a simple repo and did a reabse containing a conflict which worked as expected so this is not generally happening during rebase. I'm able to trigger the by removing the changed file in another branch but the merge view kept working. So maybe the error messages were not really related to the observed behavior. I'll try to gather more data once this happens again and copy the full log, maybe it contains more relevant output. Thanks for fixing the REBASE/MERGE_HEAD issue! :)
Okay, just triggered this again. Actually if I repeatedly open editors I get no new logs. I decided to dig into this and some breakpoints in the compiled code. I have multiple files right now. One works, the merge editor is being opened. The others don't work. When I monitor the commands being sent I see when it works. I see when it does not work. Not sure how to debug further.
That would indicate that the git-extension itself doesn't see this as conflict and doesn't event attempt to open the merge editor... Do you see the or conflict-hover for the element in question?
Yeah they both do. I just spun up a local vscode build to get better debugging capabilities and actually found the cause in my case. currently checks for in my case the Status is . Finally - Steps to reproduce: Changing the condition to worked in my case. Not sure if this is sufficient though. I would not have thought about checking for so maybe there are even more cases.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
This has landed in insiders. You can help us verifying that this works, see the hint above
/verified
Still no go. An attempt to open conflicting file produces error in :
/verified with latest insiders. "Both " correctly offers choice between two variants. Though I'd prefer a more granular approach.

Discussion:
if (!resource.leftUri) { const bothModified = resource.type === Status.BOTH_MODIFIED; <del> if (resource.rightUri && bothModified && workspace.getConfiguration('git').get<boolean>('mergeEditor', false)) { </del> <ins> if (resource.rightUri && workspace.getConfiguration('git').get<boolean>('mergeEditor', false) && (bothModified || resource.type === Status.BOTH_ADDED)) { </ins> return { command: '_git.openMergeEditor', title: localize('open.merge', "Open Merge"),