到目前为止，“hg rebase”如何对待你？你有没有发现任何错误或陷阱？在什么情况下它会替代或补充 mq？
joeforker
问问题
2272 次
3 回答
7
在简单的情况下，Rebase 非常好（没有或很少的合并冲突），但如果你有很多它们，与常规的合并 + 提交相比，它可能会更麻烦：
Rebase 会更改您的提交并更改历史记录，并且默认情况下会删除您的原始提交。如果它们在糟糕的时刻击中您，这会产生许多影响：
- 没有办法看到你是如何解决冲突的。（即原始提交和变基之间的差异，除非您选择保留它们并在推送之前手动剥离它们）
- 没有办法测试每个重新合并的修订版都可以，在提交之前编译和运行都可以。你变基，你的提交改变。（与上述相同的例外）
- 如果你真的在做分布式的东西并从许多来源共享/拉取，你必须非常小心，不要共享任何你打算变基的提交。
- 此外，如果在上述情况下，您意外地变基然后从某人那里拉出这些 pre-rebase-commits，您会得到一组双重提交，并且需要“hg 剥离”其中一组。（我没有尝试在这里合并。）
问题是变基编辑历史。这就是 SVN 在“更新”上所做的。所以，这绝对是你可以使用的东西，但如果你有很多未完成的提交并且预计会有很多冲突，我建议改为合并。
于 2009-03-01T00:10:18.023 回答
3
相对于 MQ（Mercurial Queues）的最大优势在于，当您将排队的补丁推送到更改的基础层时，您最终会得到 .rej 文件并且必须手动修复补丁。使用 rebase，您将获得一个合并，并启动您的标准合并解决方案工具。
于 2009-02-23T04:08:33.507 回答
0
我看到指向重新设置分支的标签存在问题。
.hgtags@XXXXXXXXXXXX，第 2 行：标签 'XXX' 指代未知节点
似乎标签没有正确转换。
于 2009-11-25T14:06:14.147 回答