一些 hg 变更集在移植后未合并 发生了什么脚本：mktest.hg

如何解决一些 hg 变更集在移植后未合并 发生了什么脚本：mktest.hg

我有两个 hg 分支（dev 和 stable）没有像我预期的那样合并。

1. 在 stable 上：我从 dev 中嫁接了一个单行提交。
2. 在 dev 上：更改了嫁接的一行，提交了更改。
3. 在 stable：将 dev 合并到 stable（无冲突）。

然而，在这次合并之后，stable 仍然具有该行的嫁接版本（步骤 1）。不是 dev（第 2 步）对同一行的最新更改。这是为什么？

---

文件看起来像：

This
file
to
be
merged

变更集：

1. 在 dev 上将“to”更改为“might”
2. 将变更集 1 移植到 stable
3. 在 dev 上将“可能”改回“至”
4. 将 dev 合并到 stable。结果是“可能”（而不是我希望从变更集 3 中看到的“到”）。

解决方法

抱歉这里的延迟：你一把replicator缩小到5个commit，我就知道是怎么回事了，但是我想在回答之前写一个自己的replica，这个优先级下降了很多。 ? 我用来创建提交、移植和合并的脚本 mktest.hg 出现在本答案的末尾。

这里的关键问题是合并在 Mercurial 中的实际工作方式。它使用与 Git 相同的算法：也就是说，它完全忽略任何 branch 信息，并完全忽略任何 timing 信息。它只查看三个特定提交，通过检查提交图发现，如您的图像所示。这是通过我自己的复制器制作的文本变体：

$ cd test-hg-graft/
$ cat file.txt
This
file
might
be
merged
$ hg lga
@    4:b027441200d2:draft  stable tip Chris Torek
|\   merge dev into stable (9 minutes ago)
| |
| o  3:01c6cc386a08:draft  stable Chris Torek
| |  back to "to" on stable (9 minutes ago)
| |
| o  2:ad954507e465:draft  stable Chris Torek
| |  s/to/might/ (9 minutes ago)
| |
o |  1:f7521e4f0941:draft  dev Chris Torek
|/   s/to/might/ (9 minutes ago)
|
o  0:a163d2c4874b:draft  stable Chris Torek
   initial (9 minutes ago)

lga 别名是我偷的 借来的 copied from someone else：

lga = log -G --style ~/.hgstuff/map-cmdline.lg

map-cmdline.lg 在上面链接中的位置。它只是具有更紧凑格式的 log -G（又名 glog）。

发生了什么

当我们运行时：

hg merge dev

Mercurial 找到三个特定的提交：

• 当前在 stable 上的提交，在本例中为 -r3（SHA ID 会有所不同），是两个端点提交之一。

• dev 上的目标提交是将 dev 解析为修订版的结果。例如，我们可以使用 hg id -r dev 自行完成：

  $ hg id -r dev
  f7521e4f0941 (dev)
  $ hg id -n -r dev
  1
  

  请注意，我们可以用 @ 做同样的事情来识别我们当前的修订版本，尽管 hg summary 更方便地将所有内容泄漏出来。

• 最后（或者从某种意义上说首先，虽然我们需要另外两个才能到达这里），Mercurial 从这两个提交中找到一个 merge base 提交。合并基础是 graph 中的第一个提交，可从合并的其他两个输入访问。在我们的特定情况下，这是 rev 0，因为我们在 -r0 之后立即将分支分开。

从技术上讲，合并基是在有向无环图上运行的最低公共祖先算法的输出。有关示例，请参阅 Wikipedia。可以有多个 LCA；对于这种情况，Mercurial 在（明显）随机选择一个。在我们的例子中，虽然只有一个 LCA。

找到合并基础后，Mercurial 现在运行相当于两个 diff 操作：

hg diff -r 0 -r 3

查看我们改变了什么，以及：

hg diff -r 0 -r 1

看看他们改变了什么，因为合并基础快照。¹如果我们自己这样做，我们会看到 Mercurial 看到的：

$ hg diff -r 0 -r 3
$ hg diff -r 0 -r 1
diff --git a/file.txt b/file.txt
--- a/file.txt
+++ b/file.txt
@@ -1,5 +1,5 @@
 This
 file
-to
+might
 be
 merged

（我将我的 hg diff 配置为 git = true，以便我获得可以提供给 Git 的差异——很久以前我在这里做了很多转换工作。）

就 Mercurial 而言，我们在我们的分支上什么都不做。因此，它结合了什么都不做和对file.txt进行此更改，并提出对file.txt的这一更改。该更改应用于合并基础提交中的文件。结果文件——好吧，file，在这种情况下是单数——是准备进入最终合并提交的文件，即使它们不是你想要的。

因为 Mercurial 比 Git 拥有更多的信息——特别是，哪个分支发生了一些事情——Mercurial 在这里的行为可能与 Git 不同。但实际上，对于这种操作，两者都做同样的事情。他们都找到一个合并基础快照，将快照与两个输入提交快照进行比较，并将产生的组合变更集应用到来自合并基础的文件。 Mercurial 可以更好地捕获文件重命名（因为它知道它们，而 Git，它只需要猜测）并且可以在这里做不同的合并工作，但是没有。

---

¹有些人可能反对 Mercurial 存储变更集，而不是快照。这是真的——或者更确切地说，是真的：每隔一段时间，Mercurial 就会存储一个文件的新副本，而不是对其进行更改。但是，只要我们拥有所有需要的提交，存储更改 与 存储快照 就几乎无关紧要。给定两个相邻的快照，我们可以找到一个变更集，并且给定一个快照和一个向前或向后移动的变更集，我们可以计算一个新的快照。这就是我们如何在 Mercurial（存储变更集）中提取快照，或在 Git（存储快照）中显示变更集的方式。

---

脚本：mktest.hg

#! /bin/sh

d=test-hg-graft

test "$1" = replay && rm -rf $d
if test -e $d; then
    echo "fatal: $d already exists" 1>&2
    exit 1
fi
set -e
mkdir $d
cd $d

hg init
hg branch stable

cat << END > file.txt
This
file
to
be
merged
END
hg add file.txt
hg commit -m initial

hg branch dev
ed file.txt << END
3s/to/might/
w
q
END
hg commit -m 's/to/might/'

hg checkout stable
hg graft -r 1 # pick up s/to/might/; graft makes its own commit

ed file.txt << END
3s/might/to/
w
q
END
hg commit -m 'back to "to" on stable'

hg merge dev
hg commit -m "merge dev into stable"