在 Mercurial 中，它“安全”吗？应用 mq 补丁时拉取？
go 编程语言有一个关于使用 mq 进行代码审查的页面，它指出：“自从拉动、推送以来，在应用 mq 补丁时更新和提交可能会损坏您的存储库”。
我理解为什么推送或更新可能是一个问题，但是拉动也是一个问题吗？
如果您应用了 mq 补丁并拉取，您的存储库是否会损坏？
The go programming language has a page on code reviews using mq and it states: "Since pulling, pushing, updating and committing while mq patches are applied can damage your repository".
I understand why pushing or updating could be an issue, but is pulling an issue?
If you have mq patches applied and you pull will your repository be damaged?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
答案是否。当您拉取时，您可以将更多变更集添加到本地历史记录中。应用的 MQ 补丁也作为变更集存在于变更集图中，但这并不危险，您不会丢失任何数据。
可能发生的是您已经应用了一些补丁：
然后您将这些补丁发送到上游邮件列表以供包含。有人审查补丁、提交补丁，并将变更集推送到主存储库。之后会推送其他变更集，下次拉取时，您最终会得到：
变更集
p1到p3仍然是存储库中的 MQ 补丁，但它们现在有非 - MQ 孩子们！尝试弹出它们会导致（使用 Mercurial 2.1.1）：这有点僵局。这很烦人，但并不危险。要解决此问题，您必须让 MQ 了解
p1到p3不再由 MQ 管理。您可以通过从.hg/patches/status中删除这些变更集的行来完成此操作。当这种情况发生时，MQ 最终可能会自行删除这些行 - 但这种情况很少发生，因此还没有人编写该补丁。The answer is no. When you pull, you add more changesets to your local history. The applied MQ patches also live as changesets in the changeset graph, but that's not dangerous and you will not lose any data.
What may happen is that you have applied some patches:
You then send the patches to the upstream mailinglist for inclusion. Someone reviews the patches, commits them, and pushes the changesets to the main repository. Other changesets are pushed afterwards and next time you pull you end up with:
Changesets
p1top3are still MQ patches in your repository, but they now have non-MQ children! Trying to pop them results in (with Mercurial 2.1.1):This is a bit of a dead-lock. It's annoying but not dangerous. To resolve it you must make MQ understand that
p1top3are no longer managed by MQ. You do this by removing the lines for these changesets from.hg/patches/status. MQ should probably eventually remove these lines by itself when this happens — but it happens pretty rarely so nobody has written that patch yet.如果您在存储库中应用了 MQ 补丁时意外地与上游变更集合并，这肯定会成为一个问题。这是我刚刚尝试过的一个场景，它似乎出现了问题：
hg qpush -a推送所有补丁，hg pull从上游拉取变更集code> （但不要hg update）。这将创建一个新分支（hg Heads将您所在的分支显示为qtip，tip）正在黑客攻击，您决定切换到新分支，并运行hg update -C Tip，但这样做不弹出补丁。hg merge合并分支。哎呀！您刚刚合并了一个从未qfinished的 MQ 补丁。由于 MQ 通过创建和销毁历史记录来工作，因此补丁变更集看起来就像历史记录的正常部分。但是，由于您“跳过”了已应用的补丁并将它们与非补丁变更集合并，因此您无法再弹出补丁。事实上，运行
hg qpop将中止并显示一条消息：当我使用补丁队列时，我通常只是尝试小心并有意识地拉或推，但是 go 建议的钩子页面提供了很好的保障。
请注意，您始终可以在上游变更集之上重新调整补丁的基础。有关如何执行此操作的说明，请参阅此页面。
It can certainly be an issue if you accidentally merge with the upstream changesets while you have MQ patches applied in your repository. Here's a scenario I just tried out which seems to exhibit problems:
hg qpush -ahg pull(but don'thg update). this creates a new branch (hg headsshows the branch you're on asqtipand the new branch you just pulled astip)hg update -C tip, but do so without popping your patches.hg merge. Oops! You just merged in an MQ patch that was neverqfinished.Since MQ works by creating and destroying history, the patch changesets look like normal parts of the history. However, since you "leap-frogged" over the applied patches and merged them with a non-patch changeset, you can no longer pop the patches off. In fact, running
hg qpopwill abort with a message saying:I generally just try to be careful and conscious about pulling or pushing when I'm working with a patch queue, but the hooks suggested by the go page provide a nice safeguard.
Note that you can always rebase your patches on top of upstream changesets as well. See this page for a description of how to do that.