CODEWITHSUNDEEP
version-controlmercurialdvcstortoisehg
0xC0000022L
0xC0000022L

Reputation: 21259

Partial (per-file/folder) branching/tagging in Mercurial?

In the classic VCSs (CVS/SVN) I can add new files/folders in one branch and then "tag" them with some branch tag so they appear on another branch as well (from where they may diverge again). This works by updating your working copy to a particular state and then setting the branch tag.

How can I achieve something similar in Mercurial? I searched, far and wide, but there appears to be no way of moving only a few files/folders onto another branch.

In my case some historical branch received some updates that should now be moved onto the currently active branch (that was before the repo was converted from Subversion to Mercurial). Is there any method that retains the history of these files/this folder? Or would I have to re-introduce the current state of these files to the other branch (i.e. start from scratch)?

Side-note: there are several hundred conflicting changes between the tips of both branches. That's why I'm looking for an alternative to full-fledged merging between the branches (which would also be a problem because one of the branches would cease to exist after a merge).

Upvotes: 4

Views: 357

Answers (1)

dls
dls

Reputation: 4146

The Mercurial transplant extension should do the trick. Transplant re-applies a changeset to a branch of your choice. It's commonly used as a way to move a bug fix from one branch to another (ie: from some long-running branch corresponding to a released version of code to the actively developed default branch).

Transplant is distributed with Mercurial, but you might have to enable it by adding the following lines to your Mercurial.ini (or .hgrc):

[extensions]
transplant=

From TortoiseHg you can update to the destination changeset (ie: where you are placing the fixes) and then right-click on the changeset you want to move and select "Transplant to local". Command line help can be found at the link above.

One caveat is that transplant applies to changesets, and it want to apply the entire changeset. So, if a changeset contains some changes you want to apply and some you do not, you've got to do a little more work. One way to get around this is to use the histedit extension and break such a changeset into two. This can be complex, and is not recommended if your repo is not locally contains (ie: if it's on a server somewhere). A brute-force option would be to transplant a changeset and then simply undo unwanted changes and commit those mods as a second changeset.

Upvotes: 2

Related Questions