3

我有一个项目的 4 个版本。版本 1-3 是最初不受源代码控制的“原型”（它们作为文件系统中的单独目录存在）。版本 4 从一开始就受到源代码控制，现在有很长的提交历史。

我想将这些组合起来，使版本 1-3 成为单独的变更集，其中每个变更集都是前一个的后代。版本 4 的根应该成为版本 3 的后代（当然，版本 4 的历史也不会崩溃）。

所有更改都是私有的，而不是公开的（重写历史没有问题，因为它是）。

到目前为止我所做的并尝试了什么：
1. 我在原型版本的目录中设置了新的 hg 存储库
2. 我克隆了版本 4 的存储库
3. 我将hg pull --force版本 1-3 的无关存储库拉到了克隆的存储库。

这在单个存储库中为我提供了 4 个不相关的“根”（没有祖先的变更集）。当我将它们结合起来时，我不想记住这 4 个词根。 hg rebase应该让我移动变更集并销毁原件，不像hg merge.

在这里，我将101用作“版本 1”（这是一个没有父级的单个变更集）102的修订版和“版本 2”的修订版。

尝试1：我尝试hg rebase -b 102 -d 101但得到响应nothing to rebase。大概这是因为他们没有共同的祖先（我觉得这不一致......-b 102将包括除共同祖先之外的所有祖先，在这种情况下什么都不是。）

尝试2：我尝试hg rebase -s 102 -d 101。这会导致合并冲突。我这样做hg revert --all --rev 102并hg resolve -m表明我在所有冲突中都更喜欢“版本 2”（尽管我想知道在存在添加/删除的情况下这是否真的是更喜欢一个父级而不是另一个父级的正确方法？）。但是当我提交时，我没有线性历史——修订102仍然存在！

4

3 回答 3

2

如果我hg rebase --continue作为最终命令（而不是hg commit），那么它可以完美运行。

我没有阅读文档的最后一部分：
http ://www.selenic.com/mercurial/hg.1.html#rebase

于 2013-05-18T20:44:06.160 回答
1

据我所知，最好使用--tool "internal:other"rebase 而不是恢复到修订版。

于 2013-09-05T09:58:50.253 回答
0

对我有用的 rebase 的替代方法是使用hg convert扩展和--splicemap选项。

尽管convert旨在实际从其他源代码控制系统（例如 SVN）迁移，但它也可以从 hg“转换”到 hg。

`--splicemap` 选项允许您显式设置变更集之间的子/父关系。我用它来消除源自不相关存储库的分支。Mercurial 似乎可以很好地处理这个问题，例如，具有相同名称的文件似乎在转换/拼接映射操作之后具有连续的历史记录。

我不确定这是否一定是比变基“更好”的解决方案。对于奇怪的情况（？），它可能更像是一种利基方法。一个明显的缺点是，对于大型存储库，转换过程可能需要很长时间才能运行。

拼接图文档。

于 2016-06-29T18:17:53.963 回答