Hg: How to do a rebase like git's rebase?

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.

:).

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. :).

9 +1 for the indelible changeset. – VonC Apr 20 '10 at 4:39 1 Note: off course, Git does not exactly allow you to rewrite history, only to create new one easily (utcc.utoronto. Ca/~cks/space/blog/tech/GitNewBy adding the RebaseExtension, Mercurial provides the same exact convenient way to replace an old history by a new one.

Why? Because a merge is not always the right answer, especially when your changeset should be viewed as evolutions on top of F, and not the reverse (P merged on top of O) – VonC Apr 20 '10 at 6:21 5 VonC, I agree, a merge isn't always the right choice, but I think the difference in is what one wants one's VCS history to be able to tell them. I think the history should always be able to answer questions like "What was that way I tried to integrate it at first that didn't work out and I thought was useless at the time".

Scientists keep logbooks in pen with numbered pages, and AFAIC software engineers should save every byte they've ever typed. Rewriting history, even cset parentage, but certainly CollapseExtension, etc. Violate that.It's totally a matter of personal choice. – Ry4an Apr 20 '10 at 13:46.

(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.

I have looked at the Rebase Extension, but it still isn't clear to me. Could you please explain the steps to do what I have described above? – orange80 Apr 20 '10 at 4:02 1 @jpswain09: those steps, I believe, are illustrated in mercurial.selenic.Com/wiki/RebaseProject: hg pull followed by hg rebase, or hg pull --rebase for short.

– VonC Apr 20 '10 at 4:04 1 In the case where you aren't pulling the changes in, and you have the two branches in your repo, you can do: hg up newfeature-123 followed by hg rebase -d master --keepbranches – steprobe May 26 at 9:13 I believe nothing is wrong with rebase, it's just a matter of choice. The problem is that rebase gets abused and I'm with @Ry4an on this don't rewrite history so you can know what happen and when. – Jorge Vargas Aug 1 at 4:46.

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.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.