rebase to ancestor: just do it

[Scott Palmer]

On 2011-09-09, at 11:06 AM, Ethan Tira-Thompson wrote:

> I often seem to run into the following problem:
> 
> I’m working on a smallish feature/bugfix/whatever, made a couple local commits but not ready to push it yet.
> 
> Then I’m alerted to some other bug/issue and fix that, maybe making a couple local commits on that.  This secondary issue is independent and I want to push it out for other people and go back to my main item.
> 
> "Oh crap, I forgot to start a branch and now item 2’s patches are based on my item 1 work."
> 
> "Well I’ll just rebase item 2 back to the last public changeset... oh but rebase doesn’t work on ancestors, wtf."
> 
> So now I have to do some hacks with transplanting the first changeset of item 2 to get a new head and then rebasing the rest onto that.  Same effect, but stupidly awkward.  Why can’t rebase do this directly, it’s a common nuisance that I want to rebase something to a shared changeset before pushing.  Often that changeset happens to be an ancestor, but I don't think that should matter.

+1

I have also run into this.  It is a common error that is all too easy to make.  Coming from a Subversion background where the workflow is nearly equivalent to rebasing your local changes to the tip before pushing, I can see others here hitting it as well when we roll out Mercurial to a wider audience.  In my case I believe it will take time for peoples habits to change and remember to update to the common changeset, because of the way Subversion forced them into a much more linear workflow. It would be nice to have this "out" while we are learning to adapt to a workflow better suited for DVCS.

Scott