0

I have a project with a natural long-term branch cum fork; I won't want to re-merge this with the default branch. I initially managed this fork with a bookmark, but on reflection it seemed to make more sense to have this as a named branch, so (without thinking about it too much) I created a branch at the bookmarked head (4).

o 7:default
|
| o 6:fork
| |
| o 5:fork
| |
| o 4:default
| |
o | 3:default
| |
| o 2:default
|/
o 1:default
|
o 0:default

But this means that I now have a branch plus a lonely head (4) on the default branch which isn't going to go anywhere (because it's really part of the branch/fork, and I don't plan to commit to (4) on the default branch). But this means that the repository is now somewhat untidy: I have a fork which exists partly on the default branch and partly, later, on the named branch and which, because it's on default looks as if it should be merged later. And oooh, that untidiness is a terrible thing (perhaps I should get out more).

What I'd like is either (a) to magically put selected revisions (ie, the ones leading to the now lonely head) onto the named branch, or (b) go back to plan A (bookmarks) and retrospectively put revisions on the named branch (5 & 6) back on the default branch and add a bookmark.

Possibilities:

  1. There is a question Move branch start in Mercurial which overlaps with this, but is framed in terms of an expectation that the branch will be re-merged in future. Also, I'd quite like to retain the intermediate (post-fork pre-branch) revisions as being on the branch.
  2. Use hg convert to create a copy of the repository minus the fork, create the branch, and start hand-applying changesets. Messy and rather error-prone, but doable (there aren't too many revisions in the branch).
  3. Acknowledge that life is messy and full of disappointments, that history is history, and that I should stop worrying about inessentials.
  4. or...

I'm holding out for magic.

Community
  • 1
  • 1
Norman Gray
  • 11,978
  • 2
  • 33
  • 56

1 Answers1

1

  1. Ghost merge. Merge revision 4 into revision 7. Discard all changes of rev. 4 when doing the merge.

  2. Close the head. Update to rev. 4, close the branch there.

  3. Rebase. If revisions 2, 4, 5, 6 are in the draft phase. You can rebase starting from rev. 2, moving all descendants to another branch.

Options 1 and 2 will only hide the unwanted head (history unchanged). To rewrite history, go with option 3.

  1. Rebase to default. You can also rebase from revision 5, moving that branch back to default. Using bookmarks again, as the branch never existed.
Marcos Zolnowski
  • 2,751
  • 1
  • 24
  • 29
  • 1
    Thanks – that worked perfectly! I used option 3, which meant that I preserved the topology of the branches, and the dates of revisions (both important to me), even though this changed all of the revision numbers on the rebased branch (unfortunate but inevitable). That was a lot easier than I expected (I think rebasing had occurred to me, but I'd got the impression one couldn't rebase across branches – it seems one can). – Norman Gray Jan 29 '17 at 12:50
  • You're welcome. Well, even if you rebase branches using Tortoisehg, this process can be non-intuitive. – Marcos Zolnowski Jan 29 '17 at 22:11