Rebase on to ancestor on different branch

John Peberdy johnpeb at gmail.com
Wed Nov 10 18:42:13 UTC 2010


On Wed, Nov 10, 2010 at 1:03 PM, Kevin Bullock
<kbullock+mercurial at ringworld.org> wrote:
> On Nov 8, 2010, at 8:36 AM, Chris Gorman wrote:
>
>> Hi,
>>
>> I would like to know why the following pattern is not possible.
>>
>> Having created a local feature branch (minor_feature - not intended to be shared with the world) I would like to rebase the work on it on to the tip of a well known branch (stable). However I have discovered that rebase finds nothing to be rebased in the case where stable has not progressed since branching away from it.
>>
>> I appreciate that this breaks the rule that the destination of rebase can not be an ancestor of the source but can't work out why this should be prohibited in the simple case shown. I also understand that, branches aside, the topology would not actually change during the rebase. But given that the branch names are indeed significant to the topology, it only seems to be a special case in that stable has no further revisions commited to it. With a single extra revision on the tip of stable (say pulled in from elsewhere) I can of course perform the rebase.
>
> I can't fathom what your desired result is. If stable hasn't progressed since the head on which you based your work, whether or not you gave it a different branch name, history has not branched. It's still linear.

When you have 50 or more developers in a repository you can't pollute
your branch namespace with hundreds of transient named branches. Some
people like using private named branches for features in development
and even code-review stages.

> If you're coming from Git, this might be confusing, but in hg, a branch name is merely a stamp on some (possibly disjoint) set of changesets. It's not significant to topology in any way I can imagine would impact the case under discussion.

Does the HTTP protocol not have issues when there is a large number of
named branches?


>
> Unless you're aiming to have your work rebranded as being on the 'stable' branch...? But that's a different sort of history rewriting than `hg rebase` is designed to perform.
>
> pacem in terris / mir / shanti / salaam / heiwa
> Kevin R. Bullock
>
>> o  branch:minor_feature
>> |  rev:4
>> |  changeset:746d8191aa5d
>> |
>> o  branch:minor_feature
>> |  rev:3
>> |  changeset:520f565ba7f2
>> |
>> @  branch:stable
>> |  rev:2
>> |  changeset:64e7c753c090
>> |
>> o  branch:stable
>> |  rev:1
>> |  changeset:3dc55a5c9971
>> |
>> o  branch:stable
>>    rev:0
>>    changeset:fbf1f426945c
>>
>> $hg rebase -b minor_feature
>> nothing to rebase
>>
>> --
>> Thanks
>> Chris Gorman
>>
>> _______________________________________________
>> Mercurial mailing list
>> Mercurial at selenic.com
>> http://selenic.com/mailman/listinfo/mercurial
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>



-- 
John Peberdy



More information about the Mercurial mailing list