What is the standard commit process for Hg?

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...

Answer 2

I don't know as there's a standard per se, but one of the ideas behind Mercurial is that you can commit as often as you like since it goes to your local repository. So you can commit to your heart's content as much as you like before you pull updates.

I tend not to commit very often, saving up for when I'm preparing to push, but that's me. I can see the utility of committing early and often. I do pull updates frequently as I work to cut down on merge fun.

One other thing I do is to keep a parallel clone of my working repo (cloned from the same repository as my working repo, not cloned from my working repo) so that I can check the original state of a file easily, and if need-be check in an out-of-band emergency fix or what-have-you without complicating my current change set.