3

This looks like a fairly common and straightforward requirement, but I've looked into transplant extension, rebase, import, export, etc, and I have yet to figure it out. Hopefully I am missing out something obvious.

I would like to "merge" two branches (named branches, to be specific) such that the branches themselves don't go away. Essentially, I want to pull changes from a revision but manually resolve cherrypick changes/conflicts (using my merge program).

It seems that import, export, transplant, etc generate patches and changesets that are directly applied to the current working directory. But I don't want that... instead, I want to manually determine what changes go in.

Appreciate your help.

Kostolma
  • 301
  • 1
  • 4
  • 11
  • 1
    what tool do you use ? git or mercurial ? – gor Jan 30 '11 at 12:51
  • I've upvoted Wim's answer for Mercurial down below, but I wanted to highlight the larger conceptual misunderstanding you have. In Mercurial named branches are permanent names on change sets and they *never* go away. If you do `hg update stable ; hg merge development` you likely no longer have a head on the development branch, but doing `hg update development ; ...changes... ; hg commit` makes a new head on the development branch whose parent is development and the branch is as there as ever it was. As for getting just some of the changes from dev: you can do that easily with your merge tool. – Ry4an Brase Jan 30 '11 at 16:10
  • Thanks Ry4an, you are right about my misconception. – Kostolma Jan 31 '11 at 08:53

3 Answers3

4

I would like to "merge" two branches (named branches, to be specific) such that the branches themselves don't go away.

This is the default behavior. For example, if you look at the default branch of the mercurial source code, you'll see that it regularly merges with stable. These merges do not make default or stable disappear. The merge commit just gets the local branch name.

I want to manually determine what changes go in.

Sounds to me like transplant already does that. Alternatively, you can make each change on its own feature branch and then you have full control over which features get merged into a branch.

update: there is now also a core graft command.

Wim Coenen
  • 66,094
  • 13
  • 157
  • 251
2

It looks like you could use a third branch, a consolidation branch, where you can merge whatever changeset you need from the other two branches.
You can then use (here for Git) a combination of:

git cherry-pick SHA1 --no-commit
git add --patch

to really fine-tune exactly what you need to import/merge in that third branch, as described in the SO question "Using GIT, how can I selectively pull / merge changes from anothers 'fork'?"

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

If you use git, take a look at merge strategies.

gor
  • 11,498
  • 5
  • 36
  • 42