对合并 Mercurial 中的遗留分支有一些帮助
我们目前正在开发应用程序的新版本（2.0 版）。
我们有一位运行该应用程序 1.0 版本的客户发现了一个错误。我们更新了 1.0 版的标记变更集，并找到并修复了该错误。
我们提交了更改，在我们的源代码树中创建了一个新的头。
问题是如何最好地合并它？理想情况下，我希望将其合并到 1.0 版本之后的变更集中。我不想将其合并到提示中，因为发现错误的代码实际上不再存在。
我意识到我也许应该为“v1.0 bug修复”创建一个单独的分支。
谢谢， 本
We're currently working on the new version (version 2.0) of an application.
We have a customer running version 1.0 of the app who found a bug. We updated to the tagged changeset for version 1.0 and located and fixed the bug.
We committed the change which created a new head in our source tree.
The question is how best to merge this? Ideally I would want to merge it into the changeset that followed version 1.0. I don't want to merge it into the tip because the code where the bug was found doesn't actually exist anymore.
I realise I perhaps should have created a separate branch for "v1.0 bug fix".
Thanks,
Ben
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当使用合并在存储库中移动更改时，这一切都与您拥有更改的位置和您想要它的位置的最新共同祖先有关。如果在进行此修复之前，您的存储库看起来像这样：
1.0 标记的变更集是
[b]那么您现在会看到：修复位于
[e]中。 如果是这种情况，那么你只需要这样做：然后你会得到这个：
如果在另一方面进行更改之前，你的存储库看起来像这样
： 1.0 rag 指向
[f]那么你现在就得到了这个：通过
[g]中的修复。如果您想将变更集[g]移至[d]而不带[e]和[f]> 除此之外，也没有什么好的办法。您可以使用的不太好的方法（称为“cherrypicking”）是使用“hg export”和“hg import”命令。没有任何工作流程需要精挑细选，但避免它需要一些深思熟虑。在第二种情况下，您可以通过不在 1.0 系列（作为
[f]的子级）上进行修复，而是作为您想要的两个位置的最近共同祖先的子级来避免这种情况那个改变。由于您希望在[d]和[f]中进行更改，因此您会查找它们最近的共同祖先并看到它是[b]和使用以下命令将更改作为其子项：留下此图：
此修复，
[g]是一个新头，您可以将其合并到[d]< /code> (2.0) 和[f](1.0) 根本没有任何挑选。其命令为：生成的图表为：
其中
[h]是修复后的新 2.0，[i]是修复后的新 1.0使固定。总结：你总是可以通过深思熟虑来避免挑选樱桃，但如果你不这样做，也不是世界末日
When moving a change within a repository using merge it's all about the most recent common ancestor of the place you have the change and the place you want it. If before making this fix your repo looked like this:
with the 1.0 tagged changeset being
[b]then you now have this:where the fix is in
[e]. If that's the case then you just need to do this:Then you'll have this:
If on the other hand before making the changes your repo looked like this:
where the 1.0 rag pointed to
[f]then you now have this:with the fix in
[g]. If you want to move the changeset[g]into[d]without bringing[e]and[f]along with it, there's no good way to do it. The not-so-good way available to you (called cherrypicking) is to use thehg exportandhg importcommands.No workflow requires cherry picking, but avoiding it requires a little forethought. In that second case you would avoid it by making the fix not on the 1.0 series (as a child of
[f]) but instead as a child of the most recent common ancestor of the two places you want that change. Since you want that change in both[d]and[f]you look for their most recent common ancestor and see it's[b]and make the change as a child of that using these commands:leaving you with this graph:
this fix,
[g]is a new head, and you can merge it into both[d](2.0) and[f](1.0) without any cherry picking at all. The commands for that would be:and the resulting graph would be:
where
[h]is your new 2.0 with the fix, and[i]is your new 1.0 with the fix.Summary: you can always avoid cherry picking with forethought, but it's not the end of the world if you didn't
听起来你有这样的情况：
并且想要摆脱多余的头而不合并 [fix] 中的任何更改。
选项 #1
以下命令将简单地将分支标记为关闭，并且它不会被视为额外的头，并且不会被
hg Heads和hg Branches命令隐藏：选项 # 2
以下命令将“虚拟合并”额外的头，丢弃任何更改。
--config ui.merge=internal:fail标志可防止合并工具尝试合并任何冲突，但不会阻止添加到另一个头的文件出现，因为不会进行合并与新添加的文件冲突。revert只会将所有文件更新回第一个父级的状态。你最终会得到：但 [merge] 的内容将与 [v2] 相同。
选项 #3
进行虚拟合并的另一种方法：
这将工作目录设置为 v2，但随后“伪造”Mercurial，认为 v2 和 fix 都是父目录，并将其作为合并提交。
It sounds like you have this:
and want to get rid of the extra head without merging any of the changes in [fix].
Option #1
The following commands will simple mark the branch closed, and it won't count as an extra head and be hidden from
hg headsandhg branchescommands:Option #2
The following commands will "dummy merge" the extra head, throwing away any changes.
the
--config ui.merge=internal:failflag prevents a merge tool from trying to merge any conflicts, but doesn't prevent files added to the other head from appearing, since there would be no merge conflicts with a newly added file. Therevertwill simply update all the files back to the first parent's state. You'll end up with:but the content of [merge] will be the same as [v2].
Option #3
Yet another way to do a dummy merge:
This sets the working directory to v2, but then "fakes out" Mercurial that both v2 and fix are the parents and commits it as a merge.