CODEWITHSUNDEEP
mercurialrebase
user694733
user694733

Reputation: 16043

Rebase feature branch to avoid merges

I have default branch which is public and feature branch which is private.

default 1-----4-------8
         \     \
feature   2-3---5-6-7

When i make updates to default I want them available for feature branch. I could do it with repeated merges, but then I would end up with many merges. I don't have problem with editing history; feature branch is only on my local repository.

I want to do this:

default 1-----4-8
         \       \
feature   2-3-----5-6-7

or even better:

default 1-4-8
             \
feature       2-3-5-6-7

I tried to do:

hg rebase --dest 8 --source 5

But it moved elements to wrong branch.

default 1-----4-8-5-6-7
         \       /
feature   2-3----

Branches have changes in different files, so no need to worry about complex merges.

Edit:

--keepbranches option seems to do what I want on the surface. But merge commit information seems strange: it's like MercurialHg thinks that it is still a default branch, but only renamed as feature -branch. It seems kind of hack, and I am not 100% convinced that this is the way to go.

Upvotes: 2

Views: 210

Answers (1)

Steve Kaye
Steve Kaye

Reputation: 6262

I think that your workflow is much better suited to using Mercurial Queues than it is to using rebase.

The reason being that it is not a trivial thing to change the parent of the branch to be 8 when it used to be 1 but that is exactly the effect that you get when using MQ.

Mercurial queues keeps a set of patches, one for each revision, and makes it easy to apply / unapply as required whilst you get the feature complete.

In your scenario you'd do the following:

  1. Create first patch to contain changeset 2.
  2. Create second patch to contain changeset 3.
  3. Remove all patches
  4. Pull changeset 4
  5. Apply all patches
  6. Create patch for changeset 5
  7. Create patch for changeset 6
  8. Create patch for changeset 7
  9. Remove all patches
  10. Pull changeset 8
  11. Apply all patches

This would end up in the situation that you want in your even better scenario.

Typically, you wouldn't necessarily create one patch per changeset. You'd create a patch and keep refreshing it until you were happy with it.

When you're happy that the feature is complete, you'd finialise the patches and push allowing the rest of the team to see the code.

You could look at this tutorial to get a start with MQ.

Upvotes: 1

Related Questions