使用新的“hg rebase”命令有什么经验？

Question

到目前为止，“hg rebase”如何对待你？你有没有发现任何错误或陷阱？它在什么情况下取代或补充mq？

Answer 1

在简单的情况下Rebase是非常好的（没有或很少有合并冲突），但是如果你有很多它们，那么与常规的merge + commit相比它可能会更麻烦：

Rebase更改您的提交和＆amp;更改历史记录，默认情况下会删除原始提交。如果他们在一个糟糕的时刻遇到你，那么这会产生很多影响：

• 无法了解您如何解决冲突。 （即你原来的提交和rebase之间的差异，除非你选择保留它们并在推送之前手动剥离它们）
• 无法测试每个重新定位的修订版合并确定，编译并在提交之前运行正常。你改变，你的提交改变。 （与上述相同）
• 如果你真的在做分散的东西并从许多来源分享/拉动，你必须非常小心，不要分享任何你想要改变的提交。
• 此外，如果在上面的场景中，你意外地重新绑定然后从某人那里提取这些pre-rebase-commit，你会得到一组双重提交，需要“hg strip”掉一组。 （我没有尝试过这里合并。）

问题是rebase编辑了历史。这是SVN在'更新'上做的事情。所以，它肯定是你可以使用的东西，但是如果你有许多未完成的提交并且预计会有很多冲突，我建议改为合并。

Answer 2

超过MQ（Mercurial Queues）的最大优势是，当您将排队的补丁推送到更改的基础层时，您最终会得到.rej文件，并且必须手动修复补丁。使用rebase，您可以获得合并，并启动标准的merge-rsolution工具。

Answer 3

我发现指向重新分支的标签存在问题。

  

.hgtags @XXXXXXXXXXXX，第2行：标签'XXX'指未知节点

好像标签没有正确转换。