Hg: How to do a rebase like git's rebase
In Git I can do this:
1. Start working on new feature:
$ git co -b newfeature-123 # (a local feature development branch)
do a few commits (M, N, O)
master A---B---C
\
newfeature-123 M---N---O
2. Pull new changes from upstream master:
$ git pull
(master updated with ff-commits)
master A---B---C---D---E---F
\
newfeature-123 M---N---O
3. Rebase off master so that my new feature
can be developed against the latest upstream changes:
(from newfeature-123)
$ git rebase master
master A---B---C---D---E---F
\
newfeature-123 M---N---O
I want to know how to do the same thing in Mercurial, and I've scoured the web for an answer, but the best I could find was: git rebase - can hg do that
That link provides 2 examples:
1. I'll admit that this: (replacing the revisions from the example with those from my own example)
hg up -C F hg branch -f newfeature-123 hg transplant -a -b newfeature-123
is not too bad, except that it leaves behind the pre-rebase M-N-O as an unmerged head and creates 3 new commits M',N',O' that represent them branching off the updated mainline.
Basically the problem is that I end up with this:
master A---B---C---D---E---F
\ \
newfeature-123 \ M'---N'---O'
\
newfeature-123 M---N---O
this is not good because it leaves behind local, unwanted commits that should be dropped.
- The other option from the same link is
hg qimport -r M:O hg qpop -a hg up F hg branch newfeature-123 hg qpush -a hg qdel -r qbase:qtip
and this does result in the desired graph:
master A---B---C---D---E---F
\
newfeature-123 M---N---O
but these commands (all 6 of them!) seem so much more complicated than
$ git rebase master
I want to know if this is the only equivalent in Hg or if there is some other way available that is simple like Git.
Solution 1:
VonC has the answer you're looking for, the Rebase Extension. It is, however, worth spending a second or two thinking about why neither mq nor rebase are enabled by default in mercurial: because mercurial is all about indelible changesets. When I work in the manner you're describing, which is nearly daily, here's the pattern I take:
1. Start working on a new feature:
$ hg clone mainline-repo newfeature-123
do a few commits (M, N, O)
master A---B---C
\
newfeature-123 M---N---O
2. Pull new changes from upstream mainline:
$ hg pull
master A---B---C---D---E---F
\
newfeature-123 M---N---O
3. merge master into my clone so that my new feature
can be developed against the latest upstream changes:
(from newfeature-123)
$ hg merge F
master A---B---C---D---E---F
\ \
newfeature-123 M---N---O---P
and that's really all that's necessary. I end up with a newfeature-123 clone I can easily push back to the mainline when I'm happy with it. Most importantly, however, I never changed history. Someone can look at my csets and see what they were originally coded against and how I reacted to changes in the mainline throughout my work. Not everyone thinks that has value, but I'm a firm believer that it's the job of source control to show us not what we wished had happened, but what actually happened -- every deadend and every refactor should leave an indelible trace, and rebasing and other history editing techniques hide that.
Now go pick VonC's answer while I put my soapbox away. :)
Solution 2:
You might be looking for Rebase Extension. (implemented as part of the SummerOfCode 2008)
In those cases it can be useful to "detach" the local changes, synchronize the repository with the mainstream and then append the private changes on top of the new remote changes. This operation is called rebase.
Getting from:
to:
As commented below by steprobe:
In the case where you aren't pulling the changes in, and you have the two branches in your repo, you can do (using
keepbranches):
hg up newfeature-123
hg rebase -d master --keepbranches
(--keepbranches: Inherit the original branch name.)
Mojca mentions:
I like using
hg rebase --source {L1's-sha} --dest {R2's-sha}, but I didn't know I could add--keepbranchesat the end.
As illustrated below by Jonathan Blackburn:
hg rebase -d default --keepbranches
Solution 3:
Assuming you have a modern Hg installation, you can simply add:
[extensions]
rebase =
to ~/.hgrc.
Then you can use the commands hg rebase, hg pull --rebase, or hg help rebase.
Solution 4:
I don't think the answers above achieve the OP's goal, which was to maintain his task branch, just rebased against a later point on the parent branch.
Let's say I start with this graph (generated using the graphlog extension. Serious geek love for graphlog).
@ 9a4c0eb66429 Feature 3 commit 2 tip feature3
|
| o af630ccb4a80 default againagainagain
| |
o | 98bdde5d2185 Feature 3 branch commit 1 feature3
|/
o e9f850ac41da foo
If I'm on the feature3 branch and want to rebase it off of the againagainagain commit, I understand that I would run hg rebase -d default. This has the following result:
@ 89dada24591e Feature 3 commit 2 tip
|
o 77dcce88786d Feature 3 branch commit 1
|
o af630ccb4a80 default againagainagain
|
o e9f850ac41da foo
Mission accomplished? I don't think so. The problem is that when the commits on the feature3 branch were rebased on againagainagain, the feature3 branch was deleted. My commits have been moved to the default branch, which was what I was trying to avoid in the first place.
In Git, the result would look like this:
@ 9a4c0eb66429 Feature 3 commit 2 tip
|
o 98bdde5d2185 Feature 3 branch commit 1 **feature3**
|
o af630ccb4a80 default againagainagain
|
o e9f850ac41da foo
Notice that the feature3 branch still exists, the two commits are still on the feature3 branch, and not visible on default. Without preserving the task branch, I don't see how this is functionally different from a merge.
UPDATE: I discovered the --keepbranches flag supported by hg rebase, and I'm happy to report everything is okey-dokey. Using hg rebase -d default --keepbranches, I exactly replicate the Git behavior I craved. A couple of aliases later and I'm rebasing like nobody's business.