You should just pull a little less often :), just once or a couple of times a day ought to be enough. There’s usually no need to pull after every commit, especially if you keep your commits small.
–
Laurens HolstAug 29 '12 at 8:14

This is the approach I prefer to avoid too many merge changesets. As Mark explained, the hg update does an implicit merge, so you can commit both your changes and the merge as a single changeset.
–
David LevesqueAug 29 '12 at 17:22

Plus, merging is not possible as long as you have uncommitted stuff in your local repository.
So the solution is to commit first, and pull and merge afterwards.
This will always result in two changesets, not one.(...because merging always creates a separate changeset)

But you don't commit the same stuff twice, and especially you shouldn't write the same commit message twice:

The first commit is what you actually changed ("fixed a bug in the foo bar").
The second commit is just the merge (TortoiseHG actually pre-populates the commit message with "Merge", 99% of the time I just leave it like that).

The reason is feels strange is that you delay your commit until you want to integrate with the others.

A big feature of distributed version control is that commits are local. Because they're local you should commit often — commit every time you have a small consistent chunk of work done. Your commits are not inflicted on others immediately so you wont interrupt them by making many small commits.

If you begin making more commits you'll see that your workflow becomes:

Here the ratio of merge commits to "real" commits is much more sensible.

Many people (myself included) like to use the rebase extension to avoid the merge completely. That extension linearizes the commits by faking the history so that it looks like you did your four commits after the changesets you pulled down with hg pull. The only change in workflow is that you hg rebase instead of hg merge above and then skip the final commit.