Rebase on to ancestor on different branch

[Kevin Bullock]

On Nov 10, 2010, at 12:42 PM, John Peberdy wrote:

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

...which is why named branches aren't the preferred mechanism for that use case. Named branches are fundamentally _not_ "transient"; there is no hg equivalent of `git branch -d BRANCH`.

> Some
> people like using private named branches for features in development
> and even code-review stages.

The usual ways of doing that in Mercurial are to clone locally per 'stage' or feature branch, or (more recently) bookmarks.

>> 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?

If it does (and I have no idea), then it's still not a topology issue, it's a somewhat pathological performance case. In Mercurial, the DAG is not dependent in any way on the names you assign to various commits (other than the fact that branch names are included in the changeset ID computation).

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock

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