mercurial - merge 两个不相关的 Mercurial 存储库后如何调整历史记录？

Question

我刚刚按照给定的建议 merge 了两个存储库 here .由于两个存储库完全不相关，我使用

hg convert --filemap fm rep1a rep1b
hg convert --filemap fm rep2a rep2b

将存储库 1 中的文件移动到子目录 a，将存储库 2 中的文件移动到子目录 b。现在两个存储库中都没有冲突的文件，所以我将它们 merge 了。

结果是一个具有两个父级 merge 修订的存储库，一个包含存储库 1 的历史记录，另一个包含存储库 2 的历史记录。很好!

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     

我现在想要的最后一件事是 merge 所有补丁，以便它们具有线性依赖关系图，从而有效地消除 merge 修订版“ma”。我认为解决方案是重新调整一些修订版，但我缺乏了解哪些修订版需要基于哪些修订版。我尝试了一些，但似乎没有任何效果。一次尝试产生了奇怪的问题，例如:

use (c)hanged version or (d)elete?

我该如何做最后一步？

编辑:我部分解决了这个问题。由于 rebase 似乎把事情搞砸了(或者我没有完全理解问题出在哪里)，一个不同的方法似乎工作得更好(正如 Lasse 所建议的):重写历史。

我所做的是再次将存储库拆分为原始的两部分，使用 hg convert 和 filemap，直到 merge 修订。然后我使用 hg 移植将一个存储库移植到另一个存储库中。瞧，线性历史!

2f--2e--2d--2c--2b--2a--1e--1d--1c--1b--1a

在此之后，我在此之上移植了 merge 后所做的变更集。结果:备份的实际工作副本与两个历史时间线没有区别。到现在为止还挺好!

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 扩展为所有修订创建了补丁文件列表并手动控制它们，但据我所知，历史是完美的。

Answer 1

merge 不相关的历史并不能很好地工作，因为每个变更集都是某个状态下项目的快照。如果您简单地使用 pull -f 或使用 convert 进行嫁接，您将获得一个存储库，其中包含明显不相关的历史记录嫁接在一起。你不会得到一个很好的整洁的历史记录，显示嫁接历史被添加到主项目中，就像你想要的那样一次提交。取而代之的是，您将获得一堆仅包含来自项目 A 的文件的提交，以及一堆仅包含来自项目 B 的文件的提交。简而言之，这是因为“事情实际上并没有那样发生”。将历史图表拼接在一起不会修复这些变更集的内容。

因此，唯一可用的答案是在项目 A 中一次提交一次实际重放项目 B 的历史记录，并且在 A 的目录命名空间的右侧部分。这可以通过 hg 导出 + 导入“手动”完成，也可以通过 hg convert --filemap 和移植或 rebase 的某种组合来完成。

我已经调整了您提到的维基页面以弃用该“建议”。一般来说，我根本不建议尝试做这种事情，因为“它实际上并没有那样发生”。最好在一次提交中提取项目 B 的整个历史记录，并在提交消息中提供一个指向其真实历史记录的指针。