[FEATURE] 探索支持 3-way merge editor 解决合并冲突的新交互

[Ricbet]

背景
目前 opensumi 的解决冲突功能默认是基于 vscode 的 merge-conflict 模块
也就是最常见的在单文件上显示冲突符号 7 个 '<' '=' '>'

采用当前更改 | 采用传入的更改 | 保留双方更改 | 比较变更
<<<<<<<
code1
=======
code2
>>>>>>>

所有的操作都集中在 codelens 上执行，这对于冲突代码行数较少的情况下比较方便，任何操作反馈都能在一个窗口中看到
而对于冲突代码行数较多，冲突个数也较多的情况下就比较难看得出来差异

而 vscode 在一次版本更新中提供了 3-way merge editor 视图的解决冲突的新交互
见: 3-way-merge-editor

最新版本将复选框操作默认改为 codelens 了，只有通过设置 "mergeEditor.showCheckboxes" 才会出现复选框

示例截图:

视图分上下两大块区域，上面是两个冲突文件分别与 base 分支的 diff 差异结果，下面是解决冲突后的 result 结果
整体的视觉风格和 visual studio 的合并冲突有点像

👇这是 visual studio 的

比较不同的是解决冲突的各种操作还是以 codelens 为主，而不是复选框

相关 issue
microsoft/vscode#37350: 社区用户期望在 vscode 里也能使用像是 IntelliJ 或 WebStorm 的解决冲突工具
microsoft/vscode#146091: 3-way 合并视图的 UX 设计
microsoft/vscode#157361: 新的 3-way 视图上线后网友对这个新交互的评价似乎不太友好，较多人反馈学习曲线复杂，总结一句就是 It's not fun!
microsoft/vscode#160806: 在上一个 issue 中饱受用户强力的吐槽之后，将这一功能通过配置来默认关闭了（悲催）

但微软并没有放弃这一个大的新特性，而是作为一个开关配置项并默认关闭，同时在旧版的内联编辑器右下角提供了 resolve in merge editor 按钮来跳转到 3-way 视图模式

其实在 #157361 中用户所吐槽的大多数都是一些冲突行数较少的情况，这时肯定是旧版的内联编辑器交互更友好一些

[Ricbet]

开发计划

参考 3-way 的 UX 交互和视图设计，我们采用相同的 3-way 视图来展示，但解决冲突的操作交互我比较偏向复选框而不是 codelens

- [ ] 基础代码模块设计（3-way 原型视图）
- [ ] 分支信息的展示（base、incoming、current），commit id 和 分之名称等
- [ ] editor 滑轮滚动同步
- [ ] 复选框功能实现
- [ ] 代码冲突行的边框实现（分未解决和已解决的标识）
- [ ] next、previous 交互实现
- [ ] 兼容旧版 merge conflict 并在右下角提供跳转按钮
- [ ] git diff 的 Myers 算法实现
- [ ] accept incoming（accept current）、accept combination 和 remove incoming（current）实现

进阶
- [ ] 针对变动行数较少的 diff 采用 dynamic program 算法实现
- [ ] 解决冲突的操作提供 checkbox 和 codelens 的切换配置（或同时展示？）
- [ ] 复选框右键功能（如 accept both 等）

[Ricbet]

更新
对比查看了市面上多数 ide 在 merge conflict 的体验，决定暂时先放弃参考 vscode 的这种排版布局方式，优先考虑采用 左、中、右 式的布局排版

以下是各 IDE 的解决合并冲突截图

IDEA

Araxis Merge(收费软件)

VS Code

结论
经过这么一番对比，其实不难发现，确实 IDEA 版的更直观更友好一些，体验上也更能让开发人员喜欢
所以我们会在基于 monaco 之上设计开发区别于 vscode 的 3-way merge editor

设计图

[erha19]

@Ricbet 对于每个编辑器（Pre，Current，Result）感觉少了一些标识。

另外编辑器间的引导线有啥方案吗？如果 1,2 编辑器滚动不对齐的情况是不是不太理想

[Ricbet]

@erha19 标示都会有的，会在编辑器的头部展示。
滚动的话是三个视图一起滚动的，应该不会出现不对齐的情况，其实更大的问题应该是引导线不好画

[Ricbet]

• feat: implement 3-way prototyping code #1960

[Ricbet]

默认使用 Myers Diff 算法计算 3 个 editor 文本之间的差异，相关 commit
其中左边与中间作 diff、中间再与右边作 diff，并将有差异的部分用 decoration 绘制

原型图

[Ricbet]

• 实现 line widget e76d1c4
• 渲染 3 个不同状态的颜色（insert、modify、remove）10786f0
• 实现 scroll change 同步 41d18c5
• 代码重构

现有效果

[Ricbet]

• 支持 inner changes decoration 渲染 feat: implement inner changes decoration render #1987

[Ricbet]

• 实现 diff 区域彼此之间粘性相连的效果 feat: implement stickiness connect effect #1994
• 交换 ours editor 的 margin 和 code 编辑区域的位置 feat: switch margin and code editor widget content #1995
• 渲染 3-way 视图下的 conflict actions 操作 feat: render conflict actions #2002
• 实现 3-way 视图下的 accept current conflict action 操作 feat: implement conflict actions operations #2014

现有效果

Kapture.2022-11-28.at.14.12.22.mp4

[Ricbet]

当前整体进度在 75% 左右
还有以下几个事项待解决

---

feature

• 支持解决冲突操作之后的撤回功能 feat: implement revoke conflict actions #2065
• 支持 accpet_combination 操作 feat: implement accept combination conflict actions #2079
• 在同一 diff 区域左右两边都有变更且不符合 combination 条件时，accept current 操作后左右两边的代码都新增到 result editor 视图中 feat: improve conflict action #2082
• 支持在 result editor 视图编辑代码时动态绘制 diff 区域（如在 diff 区域编写代码，可以自动扩张或缩小 diff 区域）feat: implement editing result view code update range mapping #2042
• 支持一键接受 current 或 incoming 的变更操作
• 提供上一个 or 下一个 按钮
• 支持 apply 按钮，点击后当前文件冲突解决完成
• 将多个表面接触的 diff 区域合并成一个 feat: implement contiguous region merge range #2076
  支持文档 undoing 和 redoing

optimization

• 改进项: 当某一个 diff 区域左右两边都有变更时，中间的色块绘制应该是 modify feat: implement contiguous region merge range #2076
• 针对大文件的优化（e.g 5000 行的 diff）

final

• 与 git scm 插件相结合