为什么mercurial合并了工作副本中提交的更改？

Question

我已经使用Mercurial几个星期了，并且不明白为什么当Mercurial合并来自两个存储库的已提交更改时它会在工作副本中执行它？

当然可以在不使用工作副本的情况下进行合并，从而无需更换货架等。

似乎没有必要涉及工作副本。我错过了什么吗？

Answer 1

我没有写过Mercurial，所以我不能说他们为什么这么做，但这里有一些积极的结果：

• 您可以在提交之前查看合并的结果
• 您可以在提交之前编辑合并的结果
• 鼓励您经常提交

如果你真的想做一个合并并在你的工作目录中有东西，你不忍心承诺不要担心搁置只是做：

cd ..
hg clone myrepo myrepo-mergeclone
hg -R myrepo-mergeclone merge
hg -R myrepo-mergeclone push myrepo

在同一个文件系统上，克隆几乎是即时的，并且在封面下使用硬链接，因此它几乎不占用临时工作副本的空间。

Answer 2

每个存储库只有一个工作副本by definition：

  

工作目录是存储库中的顶级目录，其中   普通版本的文件可供阅读，编辑和构建。

除非您的文件系统来自Schrödinger的cat，否则您不能同时拥有同一文件的两个版本，因此您不能拥有两个工作副本。

尽管如此，理论上可以使用短暂的克隆（每个@ Ry4an）作为合并的工作副本，解决冲突，提交，然后使其消失。你会得到一个漂亮的合并变更集和完整的工作副本。

我可以想到几种方法来实现这个目标：

1. 请愿hg团队以核心方式完成
2. 编写扩展以实现短暂克隆或其他方式
3. 搁置临时变更
4. 搁置MQ

我强烈推荐＃4，就像几乎所有的工作流场景一样。我花了好几天去研究MQ，但是一旦我做了，我就再也没有回头了。

在MQ工作流程中，您的工作副本始终是当前的修补程序。因此，对于合并情况，您可以这样做：

1. hg qrefresh
2. hg qpop -a
3. hg update -r<merge first parent>
4. hg merge [-r<merge second parent>]
5. hg commit
6. hg update qparent
7. hg qgo <working copy patch>

您不必弹出＃2中的所有补丁。每当我需要处理真正的变更集以避免将它们与补丁混合时，我总会这样做。

解决方案＃3与＃4完全相同，因为根据定义，补丁是临时变更集（这是理解MQ所需的唯一内容）。这只是不同的命令：

1. hg commit -A
2. hg update -r<merge first parent>
3. hg merge [-r<merge second parent>]
4. hg commit
5. hg update -r<working copy changeset parent>
6. hg revert -a -r<working copy changeset>
7. hg strip <working copy changeset>

如果您想保留工作副本变更集并继续提交，只需在＃5中更新。

从您的问题看来，您似乎已经知道＃4但不喜欢搁置。我认为搁置是好的，因为合并是一个根本不同的任务而不是编码（更改工作副本），搁架使上下文切换显而易见且安全。

Answer 3

正如 HgInit 的“合并”一章所述：

  

合并命令 hg merge ，将两个头部合并在一起   然后它将结果留在我的工作目录中   它没有承诺。这让我有机会检查合并是否正确。

此类检查可能包括合并中的冲突，用户必须查看：

  

在KDiff3中，您会看到四个窗格

     

  
• 左上角是原始文件。
  
• Top center向她展示了她的版本。
  
• 右上角显示了我的版本。
  
• 底部窗格是一个编辑器，其中Rose构造一个已解决冲突的合并文件。
  

因此，您需要一个工作目录（合并视图）才能完全解析合并。