0

Let's consider following two Mercurial scenarios:

Scenario A: I have linear history from rev 1 to rev 5, I create branch foobar and commit revisions 5-11 to it. Then I switch to master and commit rev 12 to master. I have two branches (master and foobar), with one head each. Nice.

Scenario B: I have a linear history from revision 1 to rev 10 (only one branch - master). I'd like to put revisions 6-10 to a new branch and continue my master from 5 onward, effectively putting myself into scenario A. I see that mercurial does not support retroactive naming of branches, so there's no way for me to transition to scenario A, but I'm thinking about hack like this one:

  1. I create a new branch (and name it foobar), and commit rev 11 to it
  2. I switch to master and do hg update -5, and then commit rev 12 to master

Do I now have two branches with one head each? If I understand correctly, the only difference between scenario A and scenario B is that in scenario B revs 5-10 are not labeled with "branch foobar", which in practice doesn't mean much, and all future behavior for scenario A and scenario B is equal. Am I right?

dijxtra
  • 2,681
  • 4
  • 25
  • 37
  • 1
    Just as a note, as long as commits 6-10 have not been made public, you can use rebase to move them to a new named branch. – Kindread Oct 06 '13 at 10:32
  • Similar question: [Mercurial move changes to a new branch](http://stackoverflow.com/q/4665549/151299) – Oben Sonne Mar 28 '14 at 21:01

1 Answers1

1

You are correct. When you do a hg update the earlier revision you will see the files as they were at that point and be able to isolate the differences from the revisions that you wanted on a branch.

Mark
  • 452
  • 2
  • 9