在这种情况下我应该“hg push -f”吗？
我有两台机器 A 和 B，它们都访问外部 hg 存储库。
我在 A 上做了一些开发，还没准备好将变更集推送到外部，并且需要切换机器，所以我使用 hgserve 将变更集推送到 B。变更集在 B 上继续，已提交，然后推送到外部存储库。
然后我拉上 A 并更新为默认/提示。这留下了之前作为分支推送到 B 的本地变更集，但由于我推送内容的方式，本地变更集中的更改已经在 default/tip 中。
我现在继续在 A 上进行更改并本地提交，但是当我尝试推送时，hg 要求我合并或执行 push -f 。我知道几乎从不推荐 push -f 。 这种情况接近于我应该使用变基的情况，但是，将“变基”的变更集我在本地或外部存储库中并不真正需要，因为它们已经通过推送到 B 有效地处于默认/提示中。
现在，我知道我可以与最新的本地变更集合并并丢弃更改，但随后我仍然必须提交合并，这会让我回到变基领域。
在这种情况下我可以执行hg push -f吗？
另外，如果我在继续提交变更集之前已更新到默认/提示，为什么从 A 推送会创建远程头？
I have two machines, A and B that both access an external hg repository.
I did some development on A, wasn't ready to push changesets to the external, and needed to switch machines, so I pushed the changesets to B using hg serve. Changesets continued on B, were committed and then pushed to external repo.
I then pulled on A and updated to default/tip. This left the local changesets that had previously been pushed to B as a branch, but because of how I pushed things around, the changes in the local changesets are already in default/tip.
I've now continued to make changes and commit locally on A, but when I try to push hg asks me to merge or do push -f instead. I know push -f is almost never recommended.
This situation is close to one where I should use rebase, however the changesets that would be "rebased" I don't really need locally or in the external repository since they are already effectively in default/tip via the push to B.
Now, I know I could merge with the latest local changeset and just discard the changes, but then I would still have to commit the merge which gets me back into rebase territory.
Is this a case where I could do hg push -f?
Also, why would pushing from A create remote heads if I've updated to default/tip before I continued to commit changesets?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会备份我的 A & B 存储库，然后尝试以下操作：
合并应确保您拥有从提示中可见的每个变更集的一个实例，以及一个没有文件更改的附加合并变更集。推送已提交的合并应该是安全的 - 尽管我会在执行此操作之前检查这一点。
Mercurial的特点之一就是它擅长合并，所以你可以尝试利用这一点。如果您对合并的效果感到紧张，您可以尝试：
更好地了解它将要做什么。
如果您确实想要一个无分支的历史记录，那么您可以创建外部存储库的一个干净克隆[如果它不是太大]，并将 A 中的更改作为补丁应用。
I would back up my A & B repositories and then try this:
The merge should ensure that you have one instance of each changeset visible from the tip, plus an additional merge changeset with no file changes. It should be safe to push the committed merge - although I would check this before doing it.
One of the features of Mercurial is that it is good at merging, so you could try to take advantage of this. If you are nervous about the effect of a merge you could try:
to get a better idea of what it is about to do.
If you really want an unbranched history, then you could create a clean clone of the external repository [if it isn't too big] and apply your changes from A as patches.