合并来自同一分支的先前被拒绝的想法如何在各种版本控制系统中发挥作用？哪家对此提供支持？
这是我有根据的猜测——这个总结准确吗？
Git 和集中式 VCS：大概，您恢复了要合并的提交。因此，您实际上是在尝试合并当前提交的祖先。我还没有尝试过，但我不认为它会得到很好的支持。我想你可以与要合并的提交的相关祖先（事后看来隐喻的“分支点”）进行三向合并（你必须识别它，因为没有记录） -但是 VCS 会支持这一点还是您必须自己做？
Mercurial，使用书签（或以与书签类似的方式使用匿名分支）：如果您勤奋地使用此方法，您将“逆转路线”并从您先前拒绝的时间点的旧提交的祖先分支它。因此，即使提交最初是在这个分支上完成的，但现在不在这个分支上（因为书签是动态的，不是不可变的，而且因为你颠倒了方向），所以根本没有问题。合并走吧！
Darcs，如果 head 和旧提交之间没有标签：虽然在 Darcs 中，乍一看好像有一条直线提交，但实际上拥有的是第一个提交或最新标签之间的依赖关系图，和头部（这根本不明显，据我所知，仍然没有工具可以可视化这一点！）。因此，如果 darcs 认为您的旧提交独立于当前头（这可能很可能，因为您已经恢复了旧提交），那么它们是看不见的独立分支，并且可以非常愉快地合并。如果darcs认为旧的提交是由head依赖的，那么这种情况大概就像git的情况一样，尽管我认为没有人完全理解darcs补丁理论，除了David Roundy。
Darcs，如果同时有一个标签：我认为这就像 git 一样，因为标签将所有不可见的头捆绑在一起，并生成一个依赖于所有这些头的单个头（这可能是最容易实现的头之一） -理解darcs补丁理论的各个方面）
脚注：为了简洁起见，我在全文中提到了“旧的提交”，尽管之前被拒绝的想法当然可能是一长串的提交。
How does merging in a previously-rejected idea from the same branch, work in various revision control systems? Which offer support for this?
Here is my educated guess - is this summary accurate?
Git and centralised VCSs: Presumably, you reverted the commit that you want to merge in. So you would be literally trying to merge in an ancestor of the current commit. I haven't tried this but I don't imagine it would be supported too well. I guess you could do a 3-way merge with the relevant ancestor (the metaphorical "branch point" in hindsight) of the commit to merge in (which you'd have to identify, because there'd be no record of it) - but would the VCS support this or would you have to do it yourself?
Mercurial, using bookmarks (or using anonymous branching in a similar way to bookmarks): If you had used this approach diligently, you would have "reversed course" and branched from an ancestor of the old commit at the point in time when you previously rejected it. Therefore the commit, even though it was originally done on this branch, now is not on this branch (because bookmarks are dynamic, not immutable, and because you reversed course), so there's no problem at all. Merge away!
Darcs, if there are no tags between head and the old commit: While in darcs it looks to the casual glance as if you have a straight line of commits, what you actually have is a dependency graph between the first commit or the most recent tag, and head (which is not at all obvious and AFAIK there is still no tool to visualise this!). So if darcs thinks your old commit was independent of the current head (which is presumably quite likely, because you've reverted the old commit), they are invisibly separate branches and can be merged quite happily. If darcs thinks the old commit is depended on by head, then this situation is presumably like the git case, though I don't think anyone fully understands darcs patch theory, except maybe David Roundy.
Darcs, if there has been a tag in the meantime: I think this would be like git, because a tag bundles all the invisible heads together and makes a single head that depends on all of them (this is possibly one of the easiest-to-understand aspects of darcs patch theory)
Footnote: For brevity I've referred to "the old commit" throughout, although the previously rejected idea could of course have been a long line of commits.
发布评论
评论（1）
使用 Git，想法是从要隔离的第一个旧提交开始创建一个分支，然后 cherry-pick 新分支上的那些旧提交。
一旦您将它们隔离在自己的分支中，您就可以将其合并到您想要的任何其他分支。
With Git, the idea would be to create a branch starting with the first of the old commits you want to isolate, and then cherry-pick those old commits on your new branch.
Once you have those isolated in their own branch, you can merge it to whatever other branch you want.