Explore UX for three-way merge

[daviddossett]

We're exploring what it could look like to enable a three-way merge workflow in VS Code. Here are some initial ideas to get the ball rolling 👍

Prototype

Here's a brief walkthrough where I set up a simple merge conflict and resolve it with a three-way merge editor:

three-way-merge-walkthrough-converted.2.mp4

Main views

Here are some quick screenshots from the prototype above:

Entry point

I've been exploring the idea of having multiple entry points from a merge conflict state. One is via the existing codelens actions ("Preview Merge")...

..and another via the SCM where there could be an icon button (icon here is just a placeholder) on the file that has conflicts:

Preview merge

Here's what the merge editor preview could look like. Here it features a mixed layout with the branches on top and the resulting code below. The branch editors are read-only while the result editor is editable.

With selections

Here are two examples where selections have been made. One with a selections from different conflicts on each branch:

...and another showing the same changes being picked on both branches:

Feedback and ideas welcome!

cc @misolori @albertelo @lszomoru @rebornix

[Snailedlt]

Would be nice to see what branch incoming and current branches are.
I always struggle to remember which one is incoming and whoch one is current.

Maybe something like showing the branchname in parenthesis next to current/incoming, or showing the branchname on hover would be a good option?

Edit:
Really looking forward to this btw! If the implementation is good I'll fully transition over to vscode for most of my projects!

[hawkticehurst]

Feedback:

Entry point:
Why not have both? I personally question if I would have noticed either of the entry points that you demonstrated (or at least I think it would've taken me a while to notice), so having multiple opportunities to discover the new feature feels better to me than aligning on one of them.

Preview merge:
I love the mixed layout view, but more generally think that offering multiple layouts is the way to go.

One potential nit is the "inconsistency" of panel order between the horizontal and vertical layouts––I was expecting the results tab to be in the middle of the horizontal layout based on you demoing the vertical layout first. With that said, I could kind of see how you were maybe trying to align the mixed layout and horizontal layouts by having the results on the bottom?

I don't think I have a strong opinion about what the horizontal/vertical layout order should be (since again I can see myself almost exclusively using the mixed layout) but probably worth discussing this a bit more/getting community feedback on. Or maybe even giving the option to let people adjust the vertical/horizontal layout order to suit their preferences?

With selections:

I actually really like the usage of checkboxes as a mechanism for selecting lines of code (iirc this is not done elsewhere in VS Code right?). I personally think it's a really clear UI/UX model.

To offer another suggestion that came to mind while watching this: a visually cleaner (but potentially less intuitive) model could be to remove the checkboxes and simply click on the highlighted lines of code you want to choose from the incoming and current panels (since they are read-only). I almost imagine it as a sort of toggle button-esque experience since you've already designed a checked (higher opacity colors/text) and unchecked (lower opacity colors/text) state for the lines of code themselves.

I still think I prefer the usage of checkboxes though.

Misc:

Setting to make this a default
I love what you've presented so much that I can easily see myself wanting this to be the default way I manage merge conflicts in VS Code (if it's implemented), so I just want to toss in a formal request that a setting to make three-way merge the default view when managing merge conflicts be added as well. Please and thank you 🙏😊

Icon buttons are no longer icon buttons?
More of a concern for future webview UI toolkit work, but I just wanted to make sure that there was an intentional decision to break the conventions of the icon button to include text in the top right corner of each panel?

I personally really like how it looks (compared to using a secondary button for example) and think the addition of text is a really important and useful way of distinguishing between the actions of each panel. But again just want to make sure this an intentional shift in how the icon button style is used?

[hawkticehurst]

Would be nice to see what branch incoming and current branches are.

@Snailedlt I think that's already been included in the design 😊

[bpasero]

@daviddossett really like it and seems to pretty much match Visual Studio in terms of UX which I felt was already a great UI when I had used it.

Can we also make sure to get VS behaviour of auto-picking every change that can be merged without conflicts, such as in this example where a change is selected for getting applied automatically since it does not result in conflicts:

I think another entry point could be a prominent action in the editor toolbar to open the merge editor. Nevertheless, I think all the entry points you suggest work for me. We probably also want a setting to let the user choose to always open the merge editor by default when opening a file with merge markers. I personally would not want to always having to click on the entry point to get into this mode, I would want it always.

Have we thought about how to represent a change in a line? Throwing in some ideas from others:

The reason I bring this up is #25887, where people ask for a way to take changes from left or right even when just comparing 2 files. I think if we solve this for the merge editor, the same solution could be used for diff editors too?

[Snailedlt]

Would be nice to see what branch incoming and current branches are.

@Snailedlt I think that's already been included in the design 😊

Ohh, you're right!

Well in that case it all looks great!

[flumacs]

I think another entry point could be a prominent action in the editor toolbar to open the merge editor. Nevertheless, I think all the entry points you suggest work for me. We probably also want a setting to let the user choose to always open the merge editor by default when opening a file with merge markers. I personally would not want to always having to click on the entry point to get into this mode, I would want it always.

similarly to what @bpasero said, would it be possible to open this way all the conflicting files - by default - with a simple command within the CLI ?

[bpasero]

👍 , I think the requirements for the command line are captured in #5770 and we want to make sure that is supported.

[Zerotask]

It would be great to see how many remaining conflicts exists (and how many got resolved).
By clicking on the "x Conflicts remaining" it would jump to the next conflict. This can be especially useful for large files.

Example:

[isidorn]

Love the direction @daviddossett 👏
Some feedback I already shared, just to repeat here for transparency:

• You are suggesting that we introduce a new editor title area. I think this works for this use case, not sure if we could get away without this?

fyi for editor @alexdima @hediet, for scm thoughts @lszomoru @joaomoreno

[miguelsolorio]

Overall, really digging the design and direction! I do think we'll need to have a separate exploration around improving the codelenses for the conflicts as the multiple actions can be hard to comprehend quickly.

I just wanted to make sure that there was an intentional decision to break the conventions of the icon button to include text in the top right corner of each panel?

+1 to this thought, we also already use a "Merge" button action for settings sync so we should make both of these button styles consistent either way we go. I'm more inclined to go with button style to avoid introducing another style (though it is used in some areas like the notebook toolbar).