简短的回答是不,这是不可能的。
我一直想写一个剧本,尽可能地接近。在冲突解决过程中,
三
索引中每个文件的副本,再加上工作树中的第四个文件。(添加不可更改的副本
HEAD
实际上,
五
每个文件的活动副本,但我们只需要保存其中的四个,因为
头部
无法更改。)可以用与
git stash
是的,这将允许通过常见的Git机制传输“正在进行的隐藏合并”。
一
这将包括
最
案例。但是,在
部分
-已解决合并根本无法保留的“reuc”撤消项,以及
全部的
合并无法记录有关高级冲突(例如重命名/重命名冲突)的一些重要信息,这些信息在执行此操作之前应该以某种方式公开。
如果您不需要撤销条目,我没有写的这个脚本可能会起作用,但是,唉,我没有写。:-)不过,基本思想是将当前(合并冲突)索引读取/复制到三个或四个未冲突的临时索引副本中:每个阶段1条目一个,每个阶段2条目一个,每个阶段3条目一个。我们还需要一个用于所有0阶段的条目,尽管这里可能可以使用原始索引。添加最后一个临时索引以保存实际工作树状态
w
,包含包含冲突标记的文件(可能是
u
提交未跟踪的文件以防有人使用
git mergetool
?).make从所有临时索引文件中提交,以某种有用的方式将它们绑定到
头部
以同样的方式
暂存
用它做一个藏匿袋
i
和
W
承诺。那就去吧
git reset --hard
,同样的方法
暂存
做。
要恢复冲突状态,首先确保所有内容都是干净的,然后将每个提交读取到临时索引中。使用生成的索引文件构建一个新的冲突索引,其中条目位于0、1、2和3阶段(视情况而定)。使用工作树提交从保存的合并中建立工作树状态
W
承诺(事实上,可能先这么做)。
一
技术上可以运输
暂存
在今天的存储库之间提交,但是
暂存
前端和内部工作使它有点棘手。因为,或者至少
一
这个脚本的要点是使传输一个正在进行的合并变得容易,无论您想到什么脚本,都需要提供一个机制和一些清晰的指令来完成这个操作。
