-5

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.

Robin Green
  • 32,079
  • 16
  • 104
  • 187

1 Answers1

1

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • That sounds like a fairly simple approach - thanks. (But don't you mean the parent of the first of the old commits?) But I still think the way I've described with Mercurial is a little better, because you can say "this branch is no longer master, we're going to post-hoc describe it as an experimental feature branch". I guess it's a matter of taste, and anyway if you rigorously follow a feature and bugfix branch methodology, this issue should not arise with any VCS, at least in this simple sort of way that I've described. That said, such a methodology is pretty heavyweight. – Robin Green Feb 08 '12 at 08:34
  • @RobinGreen: after cherry-picking, those commits are no longerpart of the master branch. And with the latest Git revision, you can describe what that new branch is for: http://stackoverflow.com/a/8858853/6309 – VonC Feb 08 '12 at 08:50