CODEWITHSUNDEEP
mercurialmerge
Tim Keating
Tim Keating

Reputation: 6641

Why do I sometimes need to merge after a pull rather than simply updating?

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?

Upvotes: 14

Views: 4632

Answers (1)

Ry4an Brase
Ry4an Brase

Reputation: 78330

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.

Upvotes: 21

Related Questions