Is it a bad idea to hg update when your working copy has changes?

Question

Seems like it would be better if you did commit followed by merge. I'm a little surprised update'ing is even allowed when your working copy has changes. Is allowing updates in such cases to avoid having commits that have two parents, which result from a merge?

Answer 1

I believe hg update will try to merge your uncommitted changes:

The following rules apply when the working directory contains uncommitted changes:

1. If neither -c/--check nor -C/--clean is specified, and:
   if the requested changeset is an ancestor or descendant of the working directory's parent, the uncommitted changes are merged into the requested changeset and the merged result is left uncommitted.
   If the requested changeset is not an ancestor or descendant (that is, it is on another branch), the update is aborted and the uncommitted changes are preserved.
2. With the -c/--check option, the update is aborted and the uncommitted changes are preserved.
3. With the -C/--clean option, uncommitted changes are discarded and the working directory is updated to the requested changeset.

That will avoid an unnecessary commit (registered in the .hg repo) for an operation (hg update) which only is about updating your working directory.

Answer 2

Mercurial encourages recording all the history of a project. If you've done some work in your working directory, why not to commit these changes providing a meaningful description of your results as a commit message and then merge your results into the main branch? It will be more clear for other people to see in two separate changesets what you have made as your normal work and what you have made just for resolving merge conflicts.

Usually an extra merge changeset is OK, but sometimes you just want to rebase your current changes on top of the main branch before committing them. You might take a look at the rebase extension. The new hg rebase command allows you to rebase already committed changeses.