When I first started using hg, update seemed to have an almost magical ability to take newly-pulled changes and integrate them into my local repo. Lately, however, I notice that even if my local changes are non-conflicting with the newly-pulled changes from somewhere else, I always have to merge, resulting in an extra changeset that duplicates a bunch of changes I already have in one of my local codelines (heads).
I want to understand what it is that provokes hg to require a merge, instead of just smooshing all the changes together with update. A conflict should clearly require a merge. What else?
The need to merge vs. update isn't about whether or not the changes conflict, it's about whether you have a split in your commit history. If you have a history like this:
[A]--[B]--[C]--UNCOMMITTEDCHANGESHERE
and you pull down --[D] your uncomitted changes will be combined with D when you update.
If, however you have committed so that you have:
[A]--[B]--[C]--[E]
and you pull you'll have:
[A]--[B]--[C]--[E]
\
-[D]
and you'll need to merge to get down to a single head.
For the record, that's a better idea. Updating with uncommitted changes is a non-reversible action, which is always a little scary. If you've committed, you can always undo/redo a merge until you're happy with the combination.
P.S. Someone is probably going to suggest the fetch extension, and they're dead wrong.