Rebase on to ancestor on different branch

[John Peberdy]

On Wed, Nov 10, 2010 at 4:10 PM, Kevin Bullock
<kbullock+mercurial at ringworld.org> wrote:
> 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`.

This is why people rely so much on rebase when dealing with named
branches. For sure there are more advanced and better ways to deal
with this but for new users coming from CVS it is very important to
keep the number of new concepts down. Mercurial prides itself and does
well staying conceptually simple.

I usually recommend using unnamed branches over named branches for
ongoing development / transient branch needs. Nevertheless this is an
issue I'm asked to fix ocaisonally. Usually the solution is a
transplant and a strip. The solution when someone wants to
collapse-rebase that goes no-where is more complicated.

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

Having to re-clone is time & space consuming and extra steps. Using
bookmarks is an additional concept to learn... not easy to teach large
numbers of people these concepts.



People coming from CVS / centralized version control are not used to
planning ahead and are used to fool-proof uncommitted workspace update
support with Eclispe. Neither exists with Mercurial and more forgiving
rebase support to easily rewrite history when they make a mistake
would go a long way to help here.

 - John


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



-- 
John Peberdy