Question

案例1：更新工作目录

$ hg update [-r REV]

这会将工作目录切换到指定的版本。但是，如果我的工作目录已修改更改，则更改将合并返回REV。我意识到我可以使用-C标志来放弃我的更改，但我试图在不同的场景中关注update命令的行为。

案例2：切换到分支

$ hg update <bname>

这会将我的工作目录切换到<bname>分支。但是，在我明确使用merge命令之前，我未提交的更改未合并。

案例3：从远程存储库

更新提取的更改集

$ hg pull
$ hg update

这再次将我的工作目录与最近pull后远程存储库中的更改集合并。

Answer 1

Mercurial 1.9.1

它与变更集之间的关系有关。如果工作目录的父变更集与要更新的目标变更集之间存在直接路径，Mercurial将尝试使用合并操作传输工作目录中的更改。因此，如果您所使用的变更集是要更新的变更集的直接后代或直接祖先，它通常会起作用。

在下图中，字母表示分支名称，数字是顺序修订号。 wd是工作目录。

当Mercurial合并未提交的更改时：

在同一分支上更新：
```
--A1----A3----A5---wd
   \          /
    A2------A4
```
以上，已根据 A5 进行了更改。如果您更新为 A4 ，Mercurial会合并未提交的更改以传输它们。
```
--A1----A3----A5---A6---wd
   \          /
    A2------A4
```
此外，如果还有其他更改集（例如 A6 ），这仍然有效，因为 A4
更新到不同的分支（这次，更新到B4）：
```
--A1----A3----A5---wd
   \          /
    B2------B4
```
以上，修订 2 和 4 位于不同的分支 B ，最近已合并回分支 A < / strong>即可。 Mercurial还将转移未提交的更改，因为 A5 和 B4 密切相关。还有：

--A1----A3----A5---A6---wd \ / B2------B4

同样，当您从远程仓库中提取新更改时，通常它们将是作为工作目录的父级的变更集的后代，因此它提供了直接关系，使得可以合并未提交的更改：

--A1----A3----A5---A6---wd \ / \ A2------A4 A7---A8---A9 (A7 through A9 pulled)

当Mercurial 不合并未提交的更改时

在同一分支上更新：

--A1----A3----A5 \ / A2------A4---A6---wd

以上，已根据 A6 进行了更改。如果您更新为 A5 ，Mercurial将拒绝，说“未完成的未提交更改”或“跨越分支”。这是因为您尝试将未提交的更改从一个头部合并到另一个头部，并且（根据定义）它们不是彼此的祖先或后代。当然，命名分支也是如此：

--A1----A3----A5 \ / B2------B4---B6---wd

绕过它

当Mercurial不会自动尝试合并未提交的更改时，您可以通过几种不同的方式将更改移动到新的父级：

搁置更改，更新，然后取消搁置（手动处理冲突）。

在MQ中制作补丁会做同样的事情，因为搁架使用相同的补丁，而不是它们的队列。您将刷新补丁，弹出补丁，更新到其他分支，然后推送补丁（手动处理冲突）。

提交变更集，将其重新绑定到另一个分支（您必须完成合并过程），然后将其导入MQ，以便它不再是变更集，而是补丁。

Answer 2

忘记分支名称，它们只不过是变更集上的元数据。如果您更新到当前工作父级的后代或祖先的修订，您的更改将被合并，否则它们将不会合并。

因此，您可以从A更新为B，如果有办法从A到B，只沿父母移动，或仅移动儿童。 E.g：

 -- A -- 1 -- 2 -- B --

在这里，您可以从A更新为B，从B更新为A，因为它们是彼此的后代和祖先。

 -- A -- 1 -- 2 -- C --
               \
                4 -- B --

在这里，您也可以从A更新为B（或从B更新为A），即使它们位于不同的分支上。但是，您不能从B更新为C，因为要这样做，您首先必须向后，然后向前。

请注意，您可以通过自己进行向后移动来解决这个问题：

(on revision B)
$ hg up 2
$ hg up C

为什么hg update命令在某些情况下合并但不是全部？

案例1：更新工作目录

案例2：切换到分支

案例3：从远程存储库

2 个答案:

当Mercurial合并未提交的更改时：

当Mercurial 不合并未提交的更改时

绕过它