57

My coworker accidentally made two commits in the default branch instead of creating new his own development branch.

How can I change this situation and moves these two commits to a new branch?

skeletank
  • 2,880
  • 5
  • 43
  • 75
void
  • 1,347
  • 2
  • 13
  • 25
  • 1
    possible duplicate of [How to move some changeset to a new branch in mercurial](http://stackoverflow.com/questions/2219756/how-to-move-some-changeset-to-a-new-branch-in-mercurial) – Peter O. Nov 27 '12 at 13:54

3 Answers3

56

Imagine the following scenario:

D
|
C
| "I want to move C and D here"
B/
|
A

Steps:

  1. hg update B
  2. hg branch "mybranch"
  3. hg commit --message "Create my branch"
  4. hg update mybranch
  5. hg graft -r C
  6. hg graft -r D

  7. hg strip -r C (this should be the revision C had originally)

    The strip command is provided by an extension that you need to enable. You can follow a guide on how to enable it on the Mercurial Wiki.

  8. hg update default
randers
  • 5,031
  • 5
  • 37
  • 64
Pilo
  • 1,210
  • 15
  • 11
  • 2
    This is great. However, to be able to use it I had to enable strip extension. To do that I had to edit `mercurial.ini` file placed in my user profile folder and add `[extensions]` section and then `strip =` in the next line. More info can be found here http://mercurial.selenic.com/wiki/StripExtension – jahu Nov 07 '14 at 10:59
  • As useful as this is, it will probably not work if the changes were pushed (at least it only worked for me the time I was working on a not et pushed revision). – jahu Jan 14 '15 at 14:18
  • thank you very much! however it's easier to understand if you name the branches something else than a,b,c,d etc in the example.. something like: production, development, feature-search, fix-broken-urls or some made up sensible names :) makes it easier to read :) – OZZIE Jul 28 '16 at 17:52
42

A major question

Have the accidental commits reached other repositories or is it just in his own? If so, you can skip to the section below 'Maybe the cat is still in the bag' otherwise you may have a fair bit of work to do.


You are not alone

See here for more discussion on how to correct the problem elsewhere on Stack Overflow. What is described is the 'proper' way to to it

  • export a patch
  • create the branch
  • import the patch
  • delete the earlier commits.


Maybe the cat is still in the bag

If the changes are only in the local copy, then a simpler solution is to

  • create the new branch
  • switch to it
  • merge the changes onto that either with your fav merge tool (go Meld) or with hg graft
  • use the hg strip command to delete the changes on the old brach
  • push the changes to the world
  • pretend like nothing ever happened, whistle a happy tune ...
Community
  • 1
  • 1
Chris McCauley
  • 25,824
  • 8
  • 48
  • 65
  • 2
    If the cat is still in the bag, the transplant extension can also help, again in a cloned repo to make sure nothing bad permanently happens to the changes. – Lasse V. Karlsen Jun 30 '11 at 07:24
9

The two answers above are both correct but, assuming one has not yet pushed the commits, there's a third way.

I just successfully used the rebase command to move a string of commits to a topic branch I had forgotten to create in the first place.

I first updated to the revision from which I wanted to create the branch on which my commmits were supposed to be, then I rebased the earliest of my commits from the wrong branch on this new one and ta-da, done.

Takes more time to explain it than to do it with TortoiseHg or even the command line, really.

nasch
  • 5,330
  • 6
  • 31
  • 52
s.m.
  • 7,895
  • 2
  • 38
  • 46
  • 2
    A small detail: after updating to the branch revision, you have to create the new branch first using hg branch, or set the branch name in the commit window in TortoiseHg. After that, the described rebase works fine and interestingly applies the new branch name. – qwertfisch Oct 24 '17 at 10:29