Mercurial linear history using hg rebase with uncommited changes

Suppose I have several commits in local repo, and some uncommited changes in working dir. After hg pull, hg update, I get a couple of new changesets from central repo which create a new head in local repo.

Now suppose, I don't want to merge those two h开发者_如何学Goeads and push, in which case I'll get the message that I have uncommited changes in working dir, when trying to merge.

As well, suppose I don't want to use hg shelve in order to shelve uncommited changes and merge without problems, but would like to create a linear history by using hg rebase, so I put my commits on top of pulled commits. When I do rebase, effectively I do a merge, as presented here, under hg rebase chapter.

Now my question is, will I get the same error message: "can't do merge, there are uncommited changes", since hg rebase does implicit merge, or not?

If yes, then I will have to use hg shelve in both cases: explicit merge of two heads and implicit merge when rebasing, no?

Thanks in advance,

Cheers

---

The simple answer is yes. hg rebase will not allow you to perform a rebase when you have uncommitted edits. There are a few solutions, none of which is perfect:

• Commit your oustanding work, do the rebase, then hg export tip > foo.patch, hg strip tip, and hg import --no-commit foo.patch.

• Use hg shelve. I can't comment on this in detail since I haven't tried it.

• Create a new named branch with hg branch <branch-name> and commit your outstanding work on the named branch. You can then use hg rebase --keepbranches --base <branch-name> --dest default to rebase your working branch on top of new changes. Personally I find working with named branches (which never escape my clone to upstream) to be a very nice way to manage this sort of workflow, since it makes it easy to move back and forth between upstream and my current project[s], and there is no penalty for committing on a branch.

---

Suppose I have several commits in local repo, and some uncommited changes in working dir. After hg pull, hg update, I get a couple of new changesets from central repo which create a new head in local repo.

If you have uncommitted changes in the working dir, and hg pull gives you a new head from upstream, hg update will tell you:

abort: crosses branches (merge branches or use --clean to discard changes)

If you try to merge, you will then get a message about not being able to merge with uncommitted changes.

All this is for very good reason: if changes aren't committed, they are subject to being lost forever when the merge machinery kicks in. You should either commit or shelve your uncommitted changes before trying to merge with or rebase onto the upstream code.

You might also look into using MQ to help you with this; MQ and rebase are designed to play well together, so if your local not-quite-finished changes are managed by MQ, all you have to do is hg qrefresh; hg pull --rebase.