0

I have a repository in which a developer has made an error while committing code to various named branches. Essentially, what happened was this :

A - B - C
 \
  W - X - D - E - Y - Z

In which ABCDE are all (supposed) to be part of the main branch, and WXYZ are commits on a new named branch. The developer failed to update to 'C' before making his changes 'D' and 'E', and then committed 'Y' and 'Z' on top of them.

I need to move 'D' and 'E' onto the main branch, without including WXYZ.

A - B - C - D - E
 \
  W - X - Y - Z

I'm not terribly savvy with Hg overall, but I'm learning, and willing. I've looked at rebase, and that doesn't appear to bring me where I need to go. I could have the dev backout his changes, and re-apply them in the proper location, but that doesn't seem 'right' exactly.

How would you go about resolving this issue?

Thanks!

reidLinden
  • 4,020
  • 4
  • 31
  • 46

2 Answers2

2

The safest way would probably be to copy the revisions from one branch to another and then back them out from the branch that they were committed to using the following commands (replace the letters with the revision numbers for those changesets):

> hg up C
> hg graft D:E
> hg up Z
> hg backout D:E
> hg commit -m "Backout changes D to E"

This leaves the default branch as it should and but leaves a few bad revisions in the named branch that were backed out in one commit.

If you want to edit history with hg rebase then you can do it with the following commands:

> hg rebase -r Y:Z -d X
> hg rebase -r D:E -d C -D

You'll probably need to change the phases of the changesets to draft before doing this (hg phase -d rev does that)

If you go the rebase route then you need to make sure that all clones of the repository are deleted and re-cloned to make sure that the removed history doesn't come back. If you have a large team then that could be dangerous which is why I suggested the first option.

Steve Kaye
  • 6,262
  • 2
  • 23
  • 27
  • thanks....I can see I've got some more learning to do. I've never seen the 'up' and 'graft' commands before. – reidLinden Aug 27 '12 at 12:57
  • well, I have no 'rebase -r' and no 'graft' commands...I just get funny errors. Also, rebasing on Y:Z slices gave me errors (using "#1:#2"). Not sure why it didn't work, but I was able to get rebase working with the '-s' switch, though my end result (on a testing clone of my db) didn't come out the way I wanted it to... – reidLinden Aug 28 '12 at 13:39
  • Sounds like you have an old version of Mercurial. `hg graft` was introduced in version 2.0 as was `hg rebase -r`. `hg rebase -D` was introduced in 2.1 (and removed in 2.3 - it should work without it now) – Steve Kaye Aug 28 '12 at 16:29
  • yup...thats it... I'm at 1.9.3...Didn't think I was that far behind! Got some work to do, I see! Thanks. – reidLinden Aug 28 '12 at 20:25
1

In addition to the excellent backout idea posted by Steve Kaye, I would recommend experimenting with patch queues using the Mercurial Queues extension. If you import D, E, Y, and Z into a patch queue you can apply patches D and E on top of B and then apply Y and Z on top of X.

If the changes to the ABCD branch were separate from the WXYZ, then this should succeed without any issues. If, however, the ABCD and WXYZ changes were similar (ie: touching the same lines in a file, renaming files, etc...) then you could get some rejected files.

dls
  • 4,146
  • 2
  • 24
  • 26
  • Yeah, I figured it would be possible with Queues, but haven't yet had(taken) the opportunity to learn how to use them yet. – reidLinden Aug 27 '12 at 12:58