Mercurial Merging only certain changesets
Asked Answered
W

5

12

Ok, so we recently converted from SVN to Mercurial.
We are using TortoiseHG normally.

In our one repository we have all of our projects, C++ / .NET / ASP. We have about 100 projects, all using common library projects.

So it would be quite difficult task to create multiple repo's for each project.

Now, we have the default branch, and let's say branchA.
I'm working on BranchA and adding my uber changes to it, and I change a common library, let's say an extension method

I want to commit this to branchA and default, how would I go about this?

However, I don't want all my changes from branchA to be merged into default, and I don't want all the other changes from default

Hopefully this is sufficient information!

Wentzel answered 7/4, 2010 at 21:41 Comment(2)
This is the wrong way to use version control to manage your projects. If you have a library shared between several projects the library should have its own repository. Manually dealing with changes like this is going to cause you endless problems in the long run.Guillerminaguillermo
@PeterGraham mega-repos are used at very large companies like Facebook with good success.Detest
A
11

There is a way to avoid this problem. You can make all your changes on separate feature branches from some baseline revision, typically the tag of the last release or some other stable point S.

That way, your change X will be on its own branch which can be merged with other branches (merges M1 and M2) without introducing unwanted changesets:

-----S--o----o---M1----o---> default
     |          /
     |---------X   feature or bugfix
     |          \
     \--o---o----M2----o-----> BranchA 

This only requires normal hg merge operations; no need for patches, Transplant or MQ.

Annulus answered 15/1, 2011 at 13:39 Comment(0)
D
23

Just to keep things a bit updated: there is the graft command which implements cherry-picking in Mercurial.

This command uses Mercurial's merge logic to copy individual changes from other branches without merging branches in the history graph. This is sometimes known as 'backporting' or 'cherry-picking'. By default, graft will copy user, date, and description from the source changesets.

Deodar answered 23/6, 2012 at 12:22 Comment(0)
A
11

There is a way to avoid this problem. You can make all your changes on separate feature branches from some baseline revision, typically the tag of the last release or some other stable point S.

That way, your change X will be on its own branch which can be merged with other branches (merges M1 and M2) without introducing unwanted changesets:

-----S--o----o---M1----o---> default
     |          /
     |---------X   feature or bugfix
     |          \
     \--o---o----M2----o-----> BranchA 

This only requires normal hg merge operations; no need for patches, Transplant or MQ.

Annulus answered 15/1, 2011 at 13:39 Comment(0)
T
5

If you separate the common code into its own repository, you can use subrepos to include it in each project.

By the way, I would recommend to have a separate repository for each project, especially if there are so many.

Tripura answered 8/4, 2010 at 9:55 Comment(0)
A
3

What is want is not merge, but cherry-pick. You can use https://www.mercurial-scm.org/wiki/TransplantExtension, but be aware about complications mentioned there.

Alphonso answered 7/4, 2010 at 22:12 Comment(0)
P
-1

You're describing "cherry picking" or doing a "partial merge" which isn't possible with Mercurial currently. You have a few options:

  • Separate your common code into its own repository.
  • Generate a diff of your changes that you made to your common code, and apply that to the default branch.
Packet answered 7/4, 2010 at 21:51 Comment(1)
Downvoted because mercurial does support cherry picking. Mercurial calls it 'transplant', and it's available using the Transplant Extension.Guillerminaguillermo

© 2022 - 2024 — McMap. All rights reserved.