vscode: Change default git conflict experience to be the inline editor

The main reason I stopped using vscode over any jetbrains editor is their 3 column merge conflict editor. Left side is your local branch, right side is the changes coming in and the middle is the result.

This is far superior to what you have. It let’s me resolve it right in the middle, I can quickly jump through conflicting lines, I can text edit it, its light years ahead

@isidorn Follow-up question to the above, can we please have a way to disable the blue button appearing via an option? If the user never wants the new view, it’d be akin to getting a popup you can’t dismiss which for me would be many dozens of times a day minimum.

Also: mass kudos to the team for revisiting this.

Yes, that is exactly how we are thinking about this and it is covered in my second to last bullet point. In the lower right corner there is a large “Open in Merge Editor” button for each file under conflict so users can easily transition to the merge editor (picture below). For users that want the Merge Editor all the time they can manually set git.mergeEditor to true in their settings.

Great decision!

Small feature request: would it possible to trigger the merge editor on-demand for a specific file?

I’m thinking about a UX like the one for Markdown files. By default you get an text editor, but there is an “Open Preview to the Side” button in the top right that you can click to get a rendered preview. Similarly, any file with conflicts could have an “Open in Merge Editor” button in the top right.

That would also help to onboard users onto this new tool.

I’m actually very surprised by this change. I started using the new merge editor since its first introduction and never looked back. The previous editor was awful for resolving complex conflicts and the new merge editor is a delight to use.

I’m now a bit afraid that the new merge editor will go away in the future again because most people seem to prefer the previous one. Will the new merge editor stay a feature in VS Code for the foreseeable future?

Also I would like to add that the experience was very much degraded for me by the switch from checkboxes to inline labels. It would be great to get this as an option back.

I love the new merge editor! I would not trust the argument of “strong preference of community”: On the Internet, most of the time, you can only hear the voice of a small, dissatisfied minority. On the other hand, happy users will stay quiet and will be ignored 😉.

I am delighted, that I can toggle the flag in settings and use the new merge editor! I have written this comment not to start a discussion, but to say to the devs, that the new merge editor is great and I am grateful for it! Keep up the good work! 🙂

I also liked the checkboxes.

Closing as merged into 1.71 with #160925

best decision ever and thanks for listening your users and reverting this decision with proper defaults, I personally greatly appreciate your changes. Thanks so much! 🙂 ❤️

@isidorn

As for the checkboxes being superior to inline labels - this is not what we were seeing in multiple user studies we conducted and in user feedback on GitHub.

For me it was by far easier to see if both, just one or none side had been chosen. Also way faster to toggle between a few versions before finding the correct merged variant. The inline labels might be easier to understand at first (it also took me a moment to understand what kind of state the checkboxes are showing me) but as soon you understand it, the checkboxes are way faster and easier to work with.

I’m having the feeling that the on-boarding to this concept was too steep, so people didn’t understand it and suggested/voted for something they were familiar with, the inline labels.

I can open a separate issue, so this can be properly tracked.

Massive Kudos for the team for this! The new view is honestly growing on me, but I doubt anything beats the inline experience for complex conflicts, especially in 3-way inline mode. My current workflow includes switching between these views.

I really appreciate you revisiting the experience and tuning it the way you have.

@mjbvz I understand the issue is closed but…could we please get an answer on the above ask? I want to make sure this doesn’t get missed because it would be a very common annoyance if we can’t disable it.

This is so disappointing.

I’m having the feeling that the on-boarding to this concept was too steep, so people didn’t understand it and suggested/voted for something they were familiar with, the inline labels.

Strongly agreed. I think it’s a classic case of:

• Implement a feature, X, with some rough edges.
• Get negative feedback.
• Assume that the negative feedback means X was fundamentally the wrong idea. When instead, the kinks just needed working out.
• Revert X.

Combined with people having an aversion to change. And, as noted above, the fact that satisfied users tend to be quiet.

To be honest, I think this applies both to the merge editor as a whole, and the checkboxes.

I can open a separate issue, so this can be properly tracked.

Did you do this? I’d like to continue the discussion somewhere.

I love how perceptive you are to the UX! It’s not easy to “walk back” a large feature based on responses… kudos!

@NickCraver please open a new issue for that and please ping me @isidorn on the issue. Thanks a lot!

I love the 3-way-view, but honestly it would be more useful to me if in the middle I saw the base version of the file to see what exactly the two conflicting changes were compared to the original. That allows me to judge and decide how to even do the merge in the first place. Resolving conflicts was no problem for me and the 3-way-merge view didn’t improve that experience (because no imporvement was necessary there). But a 3-way-comparison with the base version, now that would be a real assistance to decide how to resolve the conflicts. Edit: reading just one paragraph further in the release notes shows me you have already delivered the base comparison view 😄 thank you ❤️