撤消 Mercurial 推送
我使用 TortoiseHg 进行版本控制。我提交到本地后推送到远程存储库。如何撤消特定提交点？
共有三个不同的推动，我想恢复到第一个推动。我读到了 hg rollback 和 hg undo 命令，但我不确定如何使用它们来完成此操作。
I am using TortoiseHg for version control. I pushed to the remote repository after commiting to the local. How do I undo to a particular commit point?
There were three distinct pushes, and I want to revert to the first push. I read about the hg rollback and hg undo commands, but I am not sure how to use them to accomplish this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
因为您已推送到另一个存储库，所以您无法知道您的更改已传播到哪里。如果你没有推送，你可以撤消，但撤消无论如何只会执行最后一个事务。
真正修改历史记录的另一个选项是 strip 命令，但同样，因为您已推送，所以这不是一个选项。如果你剥离了本地的，你仍然会在下次拉取时取回变更集。
如果您有权访问中央，则可以将其剥离，但如果其他人已经拉取了您的更改，那么它们会在下次推送时再次重新出现在中央。
此时唯一安全的选择是撤销命令。这基本上会在提示处创建一个新的变更集，以反转您意外放入的变更集。
Because you have pushed to another repository, you have no way of knowing where your changes have propagated to. If you hadn't pushed, you could do undo, but undo only does the last transaction anyway.
The other option to truly modify history would be the strip command, but again, because you've pushed, this is not an option. If you stripped your local, you'd still get the changesets back the next time you pulled.
If you have access to the central, you could strip it, but if someone else has already pulled your changes, then they would re-appear in the central again the next time they push.
Your only safe option at this point in time is the backout command. This basically creates a new changeset at tip that reverses the changesets you've accidentally put in.
从“纯粹的”Mercurial 角度来看，Mike 是对的——推送的变更集超出了您的控制范围。 但是，在实践中，这往往是一个过于严格的观点。
与 Mike 所说的相反，剥离已经推送的变更集可能是一种选择。这取决于您是否可以控制中央存储库（也可以剥离那里）以及您的团队/社区的规模及其组织方式。
如果您确定没有人拉取您的错误变更集，只需删除您的本地和中央存储库 - 完成，历史记录已删除。
如果有人有可能已经提取了您的不良变更集，您还必须删除本地和中央存储库并且您必须通知所有推动团队成员删除其本地中的不良变更集回购协议（或者从剥离的中央回购协议中重新克隆）。如果你幸运的话，每个人都会按照你说的去做。否则，变更集迟早会再次出现在中央存储库中。
最重要的是，对于像您这样的情况，剥离可能是一种解决方案 - 您必须平衡成本（给您的团队带来额外的工作负担）和收益（干净的历史记录）。
一个实际的例子是，如果您不小心添加了大型二进制文件，则收益大于成本。在这种情况下，可能每个团队成员都更喜欢同步剥离，而不是使用崩溃的存储库。
更新：您可以使用服务器端挂钩来防止剥离的变更集返回到中央存储库 - 在此处了解更多信息。
From a "puristic" Mercurial perspective, Mike is right - pushed changesets are out of your control. But, in practice this is often a too strict perspective.
In opposition to what Mike said, stripping already pushed changesets may be an option. It depends on whether you have control over the central repository (to strip there too) and on the size of your team/community and how it is organized.
If you know for sure nobody has pulled your bad changesets yet, just strip your local and the central repo - done, history deleted.
If there is a chance someone pulled your bad changesets already, you'd have strip the local and central repo as well and you'd have to notify all pushing team members to strip the bad changesets in their local repos too (or to reclone from the stripped central repo). If you're lucky, everyone does what you say. Otherwise the changesets end up in the central repo again, sooner or later.
The bottom line is that stripping might be a solution for cases like your's - you have to balance the cost (burden your team with extra work) and the benefit (clean history).
A practical example where the benefit outweighs the cost would be if you've accidentally added large binary files. In that case probably every team member prefers to strip synchronously instead of working with a blown up repository.
UPDATE: You can use server side hooks to prevent stripped changesets from getting back into the central repository - read more here.
您可能想阅读hginit.com 的“修复错误”页面。您想要“退出”、合并和推送。这实际上所做的是创建一个新的提交，该提交执行与更改相反的操作并应用它。
You might want to read hginit.com's 'fixing goofs' page. You want to "back out", merge, and push. What this actually does is create a new commit that performs the inverse of the changes, and applies it.