Moving Changes to Feature Branches After-the-Fact in Mercurial

1

At my workplace we use Mercurial. We don’t usually work in feature-branches, but in the default branch instead. This is usually not problematic, but I keep running into the following situation: I started working on feature A (on the default branch), when suddenly I am forced to work on (and ship) feature B instead, for whatever reason. When that happens, I usually say to myself “God damn it! I wish I worked on A in a branch to begin with!”.

This is a companion discussion topic for the original entry at http://amir.rachum.com/blog/2012/12/29/moving-changes-to-feature-branches-after-the-fact-in/
2

I'm not sure I understand, not working on feature branches is repeatedly causing you issues at work, but you'd rather rewrite history than just work in feature branches from the outset? Can you explain the rationale?

3

First of all, issues only rise every now and then.
Secondly, I actually agree with you. However, management decided not to use feature-branches from the get-go, but rather only when it's necessary - a decision which I opposed. I am free to use feature-branches, but it is not accustomed.

4

Well, the decision to stick to the default branch in most cases has its benefits. It encourages Continuous Integration, for one.

5

Amir, when working on the main branch when developing any feature that takes more than few hours to develop you either:
1. Not commit anything to the source control until your feature development is complete - thus loosing the most important benefit of distributed source control.
2. Commit half-done code to the main branch - which is just wrong.

6

Excellent point. IMHO, it is only good if you can develop your feature in less than a days work (or better - divide the feature you develop to many less-than-a-days-work subfeatures.

7

Thanks for the interesting feature!
Just my opinion, "hg log -G" output would be more suitable to illustrate log history in the posts

8

Your second point sounds worse than it actually is. I am committing half-done work, but I'm not pushing it until there's a commit that completes it. It's still bad, I agree, but not as much. As I said, I'm personally pro feature branches.

9

Thanks for the tip :)

10

Have you considered using the mercurial queues for managing your (in-progress) feature work?

http://hgbook.red-bean.com/rea...

11

That's not what CI necessarily means, though. We work exclusively on feature branches- but we also test every single commit.

12

Had to do exactly this, and this page described a much simpler method than using export/import/strip sequences...
Just one glitch - using the latest version 2.7 hg command, it first said that rebase was not a valid command.
Turns out, have to enable the extension by adding this to .hg\hgrc:
[extensions]
rebase =
Then it all worked fine, and hg log -G shows the correct picture.

13

Outstanding! Thanks for the clear step-by-step, which saved me from looking foolish.