合并时在一个文件上调用两次的 Git 合并驱动程序答案

【问题标题】：Git merge-driver on one file called twice when merging合并时在一个文件上调用两次的 Git 合并驱动程序
【发布时间】：2018-01-26 03:28:03
【问题描述】：

在将分支合并到 master 时，我们发现合并驱动程序在一个文件上调用了两次的问题。

这里是合并配置

[merge "daff-tab"]
    name = daff tabular tab merge
    driver = D：\\tabtool/x64/release/TabTool.exe cui_merge %O %A %B %L %P

第一次

第二次

%Ps 是相同的（所以我认为一个文件合并了两次）。我注意到 %L==9 第一次，但 %L==7 第二次。如果有冲突，我就写 %A "@there are conflict"。

以下代码在第一次执行时将字符串“@there are conflict”写入 %A。

if (conflict) {
    tab_desc_write_invalid(argv[3]);
    return 1;
}

我检查了第二次调用合并驱动程序的 .merge_file_a00724 的内容，这只是第一次合并的结果。我的驱动程序无法识别此类内容，导致后期合并失败。

为什么在一次合并操作中，一个文件会合并两次？这超出了我对 git 的了解。

另外，第一次调用merge-drive时，由.merge_file_*00724引起的冲突之前好像已经解决了，但是又重新打开了。

【问题讨论】：

【解决方案1】：

这个特定的合并可能有多个合并基础，因此合并基础正在被合并以产生一个新的基础（新的但临时的提交），适合作为最终合并的输入。

要测试这个理论，请在您提供给原始合并的两个提交上运行 git merge-base --all。

如果是这种情况，您可以使用 -s resolve 策略来更改合并方法：现在，Git 将简单地选择多个合并基中的一个，而不是合并多个合并基以进行新的提交。

可能更好，您还可以为递归合并指定不同的驱动程序。请参阅the gitattributes documentation 中的recursive 设置示例。如下面的 cmets 所述，递归合并也是 increases the marker size by 2，这解释了 %L 的 7 与 9。

【讨论】：