Mercurial 不同回购协议之间的Cherry pick变更集

我有两个mercurial存储库，

generic

和

specific

，它是第一个repo的克隆：

$ hg glog -R generic 
@  changeset:   0:d516ded3bf0a
   summary:     generic project commit

$ hg glog -R specific 
@  changeset:   3:5f7b2efea94b
|  summary:     added another specific project change
o  changeset:   2:e2ad52001bcf
|  summary:     added generic project change (backport)
o  changeset:   1:a4220a2c7a80
|  summary:     added specific project change
o  changeset:   0:d516ded3bf0a
   summary:     generic project commit

现在，我想将

特定

中的变更集2向后移植到

通用

。我不想添加变更集1和3，只想添加CS2（樱桃选择）。似乎有两种选择：和。移植是可以的，因为它允许将补丁从另一个存储库（在我的例子中是从

specific

移动到

generic

），但它的合并功能有限。另一方面，嫁接将提供更智能的合并，但不支持从另一个回购协议（仅在同一个回购协议的分支之间）嫁接

目标是只将

specific

中的变更集2添加到

generic

。我就是这样进行的，没有成功

$ cd specific
$ hg up 0 # the common ancestor
$ hg branch backport-cs2
$ hg graft 2

$ hg glog
@  changeset:   4:1405acc4a121
|  branch:      backport-cs2
|  tag:         tip
|  parent:      0:d516ded3bf0a
|  summary:     added generic project change (backport)
|
| o  changeset:   3:5f7b2efea94b
| |  summary:     added another specific project change
| |
| o  changeset:   2:e2ad52001bcf
| |  summary:     added generic project change (backport)
| |
| o  changeset:   1:a4220a2c7a80
|/   summary:     added specific project change
|
o  changeset:   0:d516ded3bf0a
   summary:     generic project commit

到目前为止还不错。最后一步是将

specific

的分支

backport-cs2

拉入

generic

的默认分支

$ cd ../generic
$ hg pull -b backport-cs2 ../specific
$ hg glog 
o  changeset:   1:1405acc4a121
|  branch:      backport-cs2
|  tag:         tip
|  summary:     added generic project change (backport)
|
@  changeset:   0:d516ded3bf0a
   summary:     generic project commit

---

现在在

generic

中有一个我想要的变更集，但它位于一个新的分支中，而我希望它处于默认状态。有什么建议吗？对于更好的后移植方法的想法也很受欢迎。

一般来说，你所做的很难，因为这不是一个很好的想法。如果这些项目真的有那么多的共同点，那么它们应该有更多的共同点，而不仅仅是变更集为零。例如，理想情况下，specific会在默认情况下定期合并为“generic”——这是一种非常常见的模式。有可能对“特定”进行极端定制，或者有1000个“通用”没有的文件，或者删除100个文件，合并仍然非常好。这很难做到双向的，但是如果你将“通用”改为“默认”，你应该努力保持这种频繁的合并

例如，在一家公司中，有一个名为“skel”的存储库并不罕见，它包含所有项目的锅炉板，您可以作为“skel”的克隆启动新项目。当有人更新“skel”，比如修改使用条款文件或其他东西时，您可以将skel很好地合并到您的项目中，即使您的项目已从8个文件增加到8000个——合并仍然有效

也就是说，如果你不能做到这一点，你应该使用

移植
。使用
graft
可以更容易地合并仅，因为它可以将最近的共同祖先考虑在内，特别是使后续移植更容易。当您只是挂起第一个变更集时，这些都不适用——我怀疑您的合并将与移植案例中的合并相同，并且移植至少包含一些元数据，使得两次移植相同的变更集会引发警告

也就是说，如果您真的想走上面的路线，只需跳过
hg branch backport-cs2
行即可。当你移植时，你只需要在
specific
中的
default
分支上创建一个新的头部，这是完全正确的，然后当你拉的时候，你会在“specific”中的default上得到一个新的头部，然后你可以合并它，它将位于你想要的分支上——但不要这样做。按照预期使用合并，或者如果不能，就直接使用移植。
一般来说，你所做的很难，因为这不是一个很好的主意。如果这些项目真的有那么多的共同点，那么它们应该有更多的共同点，而不仅仅是变更集为零。例如，理想情况下，specific会在默认情况下定期合并为“generic”——这是一种非常常见的模式。有可能对“特定”进行极端定制，或者有1000个“通用”没有的文件，或者删除100个文件，合并仍然非常好。这很难做到双向的，但是如果你将“通用”改为“默认”，你应该努力保持这种频繁的合并

例如，在一家公司中，有一个名为“skel”的存储库并不罕见，它包含所有项目的锅炉板，您可以作为“skel”的克隆启动新项目。当有人更新“skel”，比如修改使用条款文件或其他东西时，您可以将skel很好地合并到您的项目中，即使您的项目已从8个文件增加到8000个——合并仍然有效

也就是说，如果你不能做到这一点，你应该使用
移植
。使用
graft
可以更容易地合并仅，因为它可以将最近的共同祖先考虑在内，特别是使后续移植更容易。当您只是挂起第一个变更集时，这些都不适用——我怀疑您的合并将与移植案例中的合并相同，并且移植至少包含一些元数据，使得两次移植相同的变更集会引发警告

也就是说，如果您真的想走上面的路线，只需跳过
hg branch backport-cs2
行即可。当你移植时，你只需要在
specific
中的
default
分支上创建一个新的头部，这是完全正确的，然后当你拉的时候，你会在“specific”中的default上得到一个新的头部，然后你可以合并它，它将位于你想要的分支上——但不要这样做。按预期使用合并，或者如果不能，只使用移植