124

I have a number of changes that I committed to my local repository, but have not yet been pushed. Since on a feature is taking longer than expected, I want to swap these changes onto a named branch before I push. How can I do this?

Casebash
  • 114,675
  • 90
  • 247
  • 350
  • 2
    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

4 Answers4

154

As suggested by Mark, the MqExtension is one solution for you problem. IMHO a simpler workflow is to use the rebase extension. Suppose you have a history like this:

@  changeset:   2:81b92083cb1d
|  tag:         tip
|  summary:     my new feature: edit file a
|
o  changeset:   1:8bdc4508ac7b
|  summary:     my new feature: add file b
|
o  changeset:   0:d554afd54164
   summary:     initial

This means, revision 0 is the base on which you started to work on your feature. Now you want to have revisions 1-2 on a named branch, let's say my-feature. Update to revision 0 and create that branch:

$ hg up 0
$ hg branch my-feature
$ hg ci -m "start new branch my-feature"

The history now looks like this:

@  changeset:   3:b5939750b911
|  branch:      my-feature
|  tag:         tip
|  parent:      0:d554afd54164
|  summary:     start new branch my-feature
|
| o  changeset:   2:81b92083cb1d
| |  summary:     my new feature: edit file a
| |
| o  changeset:   1:8bdc4508ac7b
|/   summary:     my new feature: add file b
|
o  changeset:   0:d554afd54164
   summary:     initial

Use the rebase command to move revisions 1-2 onto revision 3:

$ hg rebase -s 1 -d 3

This results in the following graph:

@  changeset:   3:88a90f9bbde7
|  branch:      my-feature
|  tag:         tip
|  summary:     my new feature: edit file a
|
o  changeset:   2:38f5adf2cf4b
|  branch:      my-feature
|  summary:     my new feature: add file b
|
o  changeset:   1:b5939750b911
|  branch:      my-feature
|  summary:     start new branch my-feature
|
o  changeset:   0:d554afd54164
   summary:     initial

That's it .. as mentioned in the comments to Mark's answer, moving around already pushed changesets generally is a bad idea, unless you work in a small team where you are able to communicate and enforce your history manipulation.

Chris
  • 27,210
  • 6
  • 71
  • 92
Oben Sonne
  • 9,893
  • 2
  • 40
  • 61
  • 4
    IMHO the drawback of this solution is that it introduces a "start new branch my-feature" dummy commit (i.e. one that does not change any files). – sschuberth Nov 27 '12 at 13:27
  • 9
    @sschuberth: I think being explicit is a good thing here. If the extra changeset is a problem for you, combine it with the succeeding one (e.g. by using the `fold` command of the now built-in [histedit](http://mercurial.selenic.com/wiki/HisteditExtension) extension). – Oben Sonne Nov 28 '12 at 12:19
  • How do you print the log with the ASCII tree? – Amir Rachum Dec 22 '12 at 21:22
  • 6
    @AmirRachum: `hg log -G` ([GraphlogExtension](http://mercurial.selenic.com/wiki/GraphlogExtension)). I've stripped off some lines manually, but it could also have been rendered completely automatically using [custom log styles](http://hgbook.red-bean.com/read/customizing-the-output-of-mercurial.html#id417618). – Oben Sonne Dec 30 '12 at 20:23
  • 2
    Enable *rebase* extension : http://mercurial.selenic.com/wiki/RebaseExtension#Configuration – 56ka Jan 08 '14 at 15:57
  • 1
    @sschuberth I agree. My workaround is to rebase your non-dummy commits onto the dummy commit's parent with the --keepbranches flag, and then hg strip your dummy commit. This is a lot of work to change a branch name, but sometimes Mercurial is dumb like that. – weberc2 Mar 05 '15 at 19:43
  • @sschuberth after branching, the explicit commit is not actually needed (as of Mercurial 4.5.3 at least:-) – Harald Oct 13 '20 at 08:39
30

You can use the MqExtension. Let's say the changesets to move are revisions 1-3:

hg qimport -r 1:3    # convert revisions to patches
hg qpop -a           # remove all them from history
hg branch new        # start a new branch
hg qpush -a          # push them all back into history
hg qfin -a           # finalize the patches
Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Mark Tolonen
  • 166,664
  • 26
  • 169
  • 251
  • I want to import 63:64 and 66:68. I am getting revision 65 is not the parent of 64 – Casebash Jan 12 '11 at 05:36
  • What do you want to do with 65? Mq can only convert consecutive changesets from a head. It turns normally immutable changesets into mutable patches that can be edited. This changes the hashes (affecting all children), so you can't skip. – Mark Tolonen Jan 12 '11 at 05:45
  • I have a number of changes (including 65) that I made on the main branch and pushed – Casebash Jan 12 '11 at 05:47
  • 1
    Don't edit changesets that have been pushed. Mq changes the hashes so they will be effectively new changesets. Only edit history that hasn't been pushed. – Mark Tolonen Jan 12 '11 at 05:52
  • If you've already pushed 65, then you should most definitely not move 63 and 64, and just settle for moving 66:68 (again, only if you have not pushed them). – Matt Jan 12 '11 at 05:52
  • Additionally, why push to a central location if your feature isn't done? Push when actually done, or push to a teammate to share your work. – Mark Tolonen Jan 12 '11 at 05:59
  • @Mark, @Matt: Both 65 and 63 branch off from 62 (unnamed branch). 63:64 have not been pushed. 65 and some revisions after 69 have been. I don't understand how this could be a problem. I am currently the sole user of my repo - pushing is a nice way to back up my work. – Casebash Jan 12 '11 at 06:01
  • @Casebash, if you push again after moving some changesets that have already been pushed, the remote repo will have both your old and new changesets, and if you pull you'll get your old changesets back. – Mark Tolonen Jan 13 '11 at 02:48
  • @Mark: True, but that's not what I was doing. 63:64 have not been pushed – Casebash Jan 13 '11 at 04:45
  • I'd also add `hg qq -c rebranch` to avoid messing with other patches that may be in queue. – anatoly techtonik Jan 11 '15 at 12:12
9

I prefer the patch solution describe here by Mark Tolonen

What I have:

hg log -G

#default branch
@  changeset:   3:cb292fcdbde1
|
o  changeset:   2:e746dceba503
|
o  changeset:   1:2d50c7ab6b8f
|
o  changeset:   0:c22be856358b

What I want:

  @  changeset:   3:0e85ae268e35
  |  branch:      feature/my_feature
  |
  o  changeset:   2:1450cb9ec349
  |  branch:      feature/my_feature
  |
  o  changeset:   1:7b9836f25f28
  |  branch:      feature/my_feature
  |
 /
|
o  changeset:   0:c22be856358b

mercurials commands:

hg export -o feature.diff 1 2 3
hg update 0
hg branch feature/my_feature
hg import feature.diff

Here is the state of my local repository

@  changeset:   6:0e85ae268e35
|  branch:      feature/my_feature
|
o  changeset:   5:1450cb9ec349
|  branch:      feature/my_feature
|
o  changeset:   4:7b9836f25f28
|  branch:      feature/my_feature
|
| o  changeset:   3:cb292fcdbde1
| |
| o  changeset:   2:e746dceba503
| |
| o  changeset:   1:2d50c7ab6b8f
|/
|
o  changeset:   0:c22be856358b

Now I need to delete the revisions 1 2 and 3 from my default branch. You can do this with strip command from mq's extension. hg strip removes the changeset and all its descendants from the repository.

Enable the extension by adding following lines to your configuration file (.hgrc or Mercurial.ini):

vim ~/.hgrc and add :

[extensions]
mq =

And now strip this repository on revision 1.

hg strip 1

and here we are

@  changeset:   3:0e85ae268e35
|  branch:      feature/my_feature
|
o  changeset:   2:1450cb9ec349
|  branch:      feature/my_feature
|
o  changeset:   1:7b9836f25f28
|  branch:      feature/my_feature
|
o  changeset:   0:c22be856358b

note: changesets are different but revisions are the same

Community
  • 1
  • 1
Guillaume Vincent
  • 13,355
  • 13
  • 76
  • 103
5

For those inclined to use GUI

  1. Go to Tortoise Hg -> File -> Settings then tick rebase .

enter image description here

  1. Restart tortoise UI

  2. Create new branch where you will be moving changes. Click on current branch name -> choose Open a new named branch -> choose branch name.

enter image description here

  1. If changes you want to move have not been made public (e.g draft) go to 5. (If changes have already been published and you are not a senior dev you should talk to someone senior (get a scapegoat) as you might screw things up big time, I don't take any responsibility :) ).

Go to View -> Show Console (or Ctrl + L) then write in console hg phase -f -d 2 - where 2 is lowest revision you will be moving to new branch.

  1. Go to branch and revision (should be topmost revision if you are moving changes to new branch created in step 3.) Right Mouse -> Update

  2. Go to branch and revsion you will be moving changes from Right Mouse -> Modify History -> Rebase

enter image description here

  1. Click Rebase and pray there are no conflicts, merge if you must.

  2. Push changes, at this point all revisions should still be draft.

  3. Go to topmost revision in branch you were moving changes to Right Mouse -> Change Phase to -> Public.

enter image description here

Hope this saves you some time.

Matas Vaitkevicius
  • 58,075
  • 31
  • 238
  • 265
  • Great job! going to try this, just one question though - why change the phase to public at the end? "Any changesets seen in a remote repository are public" so when you push wouldn't it be set to public anyway? – Joshua Duxbury Jun 30 '16 at 15:09
  • @JoshLeeDucks When pushing they don't change to `public` automagically anymore (at least for me they don't). – Matas Vaitkevicius Jun 30 '16 at 15:11