为什么我有时需要在拉动后合并而不是简单地更新?

Tim*_*ing 13 merge mercurial

当我第一次开始使用hg时,更新似乎具有几乎神奇的能力来采取新拉动的变化并将它们集成到我的本地仓库中.然而,最近,我注意到即使我的本地更改与其他地方新推出的更改没有冲突,我总是必须合并,从而产生一个额外的更改集,它复制了我在其中一个更改中的一些更改本地代码行(头).

我想了解是什么引起hg要求合并,而不仅仅是将所有更改与更新一起消失.冲突显然需要合并.还有什么?

Ry4*_*ase 21

合并与更新的需求不是关于更改是否冲突,而是关于您是否在提交历史记录中存在拆分.如果你有这样的历史:

[A]--[B]--[C]--UNCOMMITTEDCHANGESHERE
Run Code Online (Sandbox Code Playgroud)

然后你下拉 - [D]你的未经修改的更改将在你更新时与D结合使用.

但是,如果你已经承诺,你有:

[A]--[B]--[C]--[E]
Run Code Online (Sandbox Code Playgroud)

而你拉你将拥有:

[A]--[B]--[C]--[E]
             \
              -[D]
Run Code Online (Sandbox Code Playgroud)

而且你需要合并才能达到一个单一的目标.

为了记录,这是一个更好的主意.使用未提交的更改进行更新是一种不可逆转的操作,这总是有点可怕.如果您已经提交,则可以随时撤消/重做合并,直到您对组合感到满意为止.

PS有人可能会建议fetch扩展,他们错了.

  • Fetch将3个完全独立的动作(`pull`,`update`和`merge`)混合在一起,同时产生无用的提交消息.使用DVC在这里和那里移动变换集(mercurial中的推/拉和使用git的push/fetch)在逻辑上不同于更新工作目录和合并头.当您使用一个命令执行所有操作时,您会得到糟糕的错误语义,错误的提交消息,如果您开始可能会对哪些命令改变本地文件,本地存储库和远程存储库感到困惑. (4认同)
  • 重新确定会产生线性历史,但它是一个稍微不诚实的线性历史(因为开发不是线性的;它是并发的).有些人更喜欢这样,但我宁愿我的历史真实而准确地反映出事情的顺序.这最终都与个人偏好(或团队政策)有关. (2认同)