0

最近，我的一位同事移植了一个提交，该提交更改了 .hgsubstate 上的一个（三个中的一个）子存储库。移植改为更改所有三个以匹配原始变更集（即使它们是从前一个更改的）：

changeset main:
f60c22f43d335e95a95301aee58a092b63800e4b external/a
26e615cf033cffa9fba77d2369e3802cc2b9a95e external/b
ca46ca7e5243439de09a2d14ffa60432c6c56d74 external/c             

diff of changeset grafted:
 7fe8fcdd7648e14bee5889a4b3155fde49f09de4 external/a
 5b90cf021b0006c8681247a73e9940f835a959f4 external/b
-8479ff0a18dc684db7f0771ace700915c51e92e6 external/c
+69e97bdab56155fee6ab4d0d21bbf36b34b040f8 external/c

final graft:
7fe8fcdd7648e14bee5889a4b3155fde49f09de4 external/a
5b90cf021b0006c8681247a73e9940f835a959f4 external/b
69e97bdab56155fee6ab4d0d21bbf36b34b040f8 external/c

似乎嫁接正在取代文件批发，而不仅仅是它的具体变化。这与我对嫁接应该做什么的直觉背道而驰。更糟糕的是，即使我使用 -t internal:fail 它也会这样做，它不会让我合并任何东西。

我至少想知道为什么会发生这种不幸的合并，这样我们将来就可以避免它。我试图在一个玩具示例上重现该问题，但我失败了；由于大约有 350 次提交/合并将两个变更集分开，我很可能错过了有问题的部分。

我的问题是：我可以让反复无常的输出来做这个移植所采取的步骤吗？或者以某种方式确定有问题的合并的来源？

4

1 回答 1

0

移植操作是使用移植父版本作为基础的 3 路合并。图表中的其他任何内容都不重要。

来源：https ://groups.google.com/forum/#!topic/mercurial_general/3pHTx8gT208

看来我的问题出在其他地方，但我现在可以结束这个问题了。

于 2014-06-09T11:49:54.720 回答