Question

Is it

1. pull
2. update
3. merge
4. commit
5. push

? Or can you do the commit first?

I don’t like the idea of pulling and merging without having a version of my local code backed up somewhere in case the merge explodes, but presumably you have to do the merge before you can do a push, because you can’t have conflicts in the central repo. Not quite understanding this whole process yet; used to my nice simple SVN.

Answer 1

I recommend to always commit before pulling in changes to your working directory, unless you are 100% sure that your changes and the changes to be merged into your working directory will not conflict.

If you do an updating pull (hg pull; hg update, or shorter hg -u pull) and have any outstanding non-committed changes, any changes coming from outside will be combined with your changes. When conflicts happen, it might be difficult to decide how the merge result should look like, because you can’t easily distinguish between your changes and the changes merged in.

When you did commit first, it is much easier to decide how the merge result should look like, because you can always look at both parents of the merge.
So, in effect it is:

1. hg commit
2. hg pull -u (if no merge necessary, go to 5)
3. hg merge
4. hg commit
5. hg push

Update: As Martin Geisler has pointed out, it is possible to get at the “original” changed version of a file using:

hg resolve --unmark the-file
hg resolve --tool internal:local the-file

or for all files at the same time:

hg resolve --unmark --all
hg resolve --tool internal:local -all

Still, I find the “commit first” system nicer. At the end, it is personal preference…