Git提交未完成的合并

简短的回答是不,这是不可能的。

我一直想写一个剧本,尽可能地接近。在冲突解决过程中, 三 索引中每个文件的副本,再加上工作树中的第四个文件。(添加不可更改的副本 HEAD 实际上, 五 每个文件的活动副本,但我们只需要保存其中的四个,因为 头部 无法更改。)可以用与 git stash 是的,这将允许通过常见的Git机制传输“正在进行的隐藏合并”。 ^一 这将包括 最 案例。但是,在 部分 -已解决合并根本无法保留的“reuc”撤消项,以及 全部的 合并无法记录有关高级冲突(例如重命名/重命名冲突)的一些重要信息,这些信息在执行此操作之前应该以某种方式公开。

如果您不需要撤销条目,我没有写的这个脚本可能会起作用,但是,唉,我没有写。:-)不过,基本思想是将当前(合并冲突)索引读取/复制到三个或四个未冲突的临时索引副本中:每个阶段1条目一个,每个阶段2条目一个,每个阶段3条目一个。我们还需要一个用于所有0阶段的条目,尽管这里可能可以使用原始索引。添加最后一个临时索引以保存实际工作树状态 w ,包含包含冲突标记的文件(可能是 u 提交未跟踪的文件以防有人使用 git mergetool ?).make从所有临时索引文件中提交,以某种有用的方式将它们绑定到 头部 以同样的方式 暂存 用它做一个藏匿袋 i 和 W 承诺。那就去吧 git reset --hard ,同样的方法 暂存 做。

要恢复冲突状态,首先确保所有内容都是干净的,然后将每个提交读取到临时索引中。使用生成的索引文件构建一个新的冲突索引,其中条目位于0、1、2和3阶段(视情况而定)。使用工作树提交从保存的合并中建立工作树状态 W 承诺(事实上,可能先这么做)。

^一 技术上可以运输 暂存 在今天的存储库之间提交,但是 暂存 前端和内部工作使它有点棘手。因为,或者至少 一 这个脚本的要点是使传输一个正在进行的合并变得容易,无论您想到什么脚本,都需要提供一个机制和一些清晰的指令来完成这个操作。