我刚刚根据给出here的建议合并了两个存储库。由于两个存储库完全不相关，我使用
hg convert --filemap fm rep1a rep1b
hg convert --filemap fm rep2a rep2b
将存储库1中的文件移动到子目录a，将文件从存储库2移动到子目录b。现在两个存储库中没有冲突的文件，所以我将它们组合在一起。
结果是一个存储库，其中包含两个父项的合并修订，一个包含存储库1的历史记录，另一个包含存储库2. Nice！
mb--ma--2f--2e--2d--2c--2b--2a
\
-------------------------1e--1d--1c--1b--1a
现在我真正想要的是补丁按时间排序的历史记录。这没问题，我使用了hg convert --datesort src dst，一切看起来还不错：
mb--ma--2f------2e--2d------2c--2b--2a
\
-----1e----------1d--------------1c--1b--1a
我现在想要的最后一件事就是合并所有补丁，使它们具有线性依赖图，有效地消除了合并修订版“ma”。我认为解决方案是对一些修订进行修改，但我缺乏理解哪个版本需要重新修改。我试验了一些，但似乎没有像预期的那样工作。一次尝试产生了一些奇怪的问题：
use (c)hanged version or (d)elete?
我该怎样做最后一步？
编辑：我部分解决了这个问题。由于rebase似乎搞砸了（或者我没有完全理解问题是什么），一个不同的approch似乎工作得更好（正如Lasse所建议的）：重写历史。
我所做的是将存储库再次拆分为原始的两个部分，使用hg convert with filemap，直到合并修订版。然后我使用hg移植将一个存储库移植到另一个存储库中。瞧，线性历史！
2f--2e--2d--2c--2b--2a--1e--1d--1c--1b--1a
在此之后，我移植了合并后我做的更改集。结果：实际工作副本与具有两个历史时间轴的备份没有差异。到目前为止，太棒了！
mb--2f--2e--2d--2c--2b--2a--1e--1d--1c--1b--1a
现在修订版没有按时间排序，这是理想的，所以我尝试了一个hg convert --datesort repository.src repository.sorted，但结果仍然有如上所示的相同顺序的变更集。如果有人知道如何做到这一点，我可以手工分类。
编辑2：我终于解决了这个问题，我创建了一个新的存储库
mkdir repository_c
cd repository_c
hg init .
我使用hg transplant：
hg transplant --source ../src 0:53
hg transplant --source ../src 70
hg transplant --source ../src 54:55
hg transplant --source ../src 71:79
hg transplant --source ../src 55:60
...
这完成了工作，历史是线性的，补丁按正确的顺序排序。由于没有冲突的补丁，并且头版本与具有两个时间轴的原始存储库相同，我很高兴。我确实使用MQ扩展为所有修订创建了一个补丁文件列表并手动控制它们，但从我可以看出历史是完美的。
答案 0 :(得分：3)
合并不相关的历史记录效果不佳，因为每个变更集都是某个州的项目快照。如果您只是简单地使用-f或者使用转换进行移植，那么您将获得一个存储库，其中包含明显无关的历史记录。你不会得到一个漂亮整洁的历史记录，它显示了嫁接历史被添加到主项目中的提交，就像你想要的那样。相反，你只会从项目A获得一堆文件提交，而只有一组只包含来自项目B的文件。简而言之，这是因为“事情实际上并没有发生这种情况”。将历史图表拼接在一起不会修复这些变更集的内容。
因此唯一可用的答案是实际重播项目A中的项目B的历史记录，一次一个提交，以及A的目录名称空间的右侧部分。这可以通过hg export + import“手动”完成，也可以使用hg convert --filemap和移植或rebase的某种组合完成。
我已经调整了您提到的维基页面以弃用该“建议”。一般来说，我不建议尝试做这类事情，因为“实际上并没有这样做”。最好只在一次提交中提取项目B的整个历史记录，并在提交消息中返回指向其真实历史记录的指针。