为什么我有时需要在拉取后合并而不是简单地更新？
当我第一次开始使用 hg 时，update 似乎有一种近乎神奇的能力，可以接受新拉取的更改并将它们集成到我的本地存储库中。然而，最近我注意到，即使我的本地更改与从其他地方新拉取的更改不冲突，我也总是必须合并，从而产生一个额外的更改集，该更改集重复了我的一个中已有的一堆更改。本地代码线（头）。
我想了解是什么促使 hg 要求合并，而不是仅仅将所有更改与更新合并在一起。冲突显然需要合并。还有什么？
When I first started using hg, update seemed to have an almost magical ability to take newly-pulled changes and integrate them into my local repo. Lately, however, I notice that even if my local changes are non-conflicting with the newly-pulled changes from somewhere else, I always have to merge, resulting in an extra changeset that duplicates a bunch of changes I already have in one of my local codelines (heads).
I want to understand what it is that provokes hg to require a merge, instead of just smooshing all the changes together with update. A conflict should clearly require a merge. What else?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
合并与更新的需要并不在于更改是否冲突，而在于您的提交历史记录中是否有分裂。如果您有这样的历史记录：
并且您下拉--[D]，您未提交的更改将在您更新时与 D 合并。
但是，如果您已经承诺，那么您将拥有：
并且您拉动您将拥有：
并且您将需要合并以达到单一的目的。
根据记录，这是一个更好的主意。使用未提交的更改进行更新是一个不可逆的操作，这总是有点可怕。如果您已经承诺，您可以随时撤消/重做合并，直到您对组合感到满意为止。
PS 有人可能会建议使用
fetch扩展，但他们完全错了。The need to merge vs. update isn't about whether or not the changes conflict, it's about whether you have a split in your commit history. If you have a history like this:
and you pull down --[D] your uncomitted changes will be combined with D when you update.
If, however you have committed so that you have:
and you pull you'll have:
and you'll need to merge to get down to a single head.
For the record, that's a better idea. Updating with uncommitted changes is a non-reversible action, which is always a little scary. If you've committed, you can always undo/redo a merge until you're happy with the combination.
P.S. Someone is probably going to suggest the
fetchextension, and they're dead wrong.