commit-pull-merge-push or pull-merge-commit-push?

Question

We started using Mercurial a several weeks ago. Most developers follow this workflow:

• work on a feature
• commit -m "Worked on feature ABC"
• pull -u
• If branch
  • merge
  • commit -m "Merge"
  • push

Today, one of our developer suggested that we do:

• work on a feature
• pull -u
• if branch
  • merge
• commit -m "Worked on feature ABC"
• push

That way, we have a lot less "Merge" changesets in the log.

Some of us think it's just a matter preference. Some of us think one is better than the other. We don't have much experience and don't want to live the downsides of misusing the tool. So if one approach is more advisable then the other, please let me know why.

Answer 1

I like your original procedure more, but reasonable people can certainly disagree. I consider merging an actual piece of software development work and like having it be a first class citizen in our process.

In your second/suggested procedure the risk is that the pull does some stuff you really don't want and then you have a very hard time separating it from the work you've already done.

For people who just can't stand branchy history the usual preferred workflow is:

• work on a feature
• commit
• pull --rebase
• push

where the --rebase option appears on pull after you enable the rebase extension. I'm not a fan of rebase because it's technically rewriting history which is antithetical to how mercurial is supposed to work, but I'm in a rapidly shrinking minority on that point.

Bottom line, if you really don't want a branchy history use rebase -- don't update into uncommitted changes as it's hard to undo.

Answer 2

I would go with your first workflow. The main objection I have with the second option, is that if you try to merge before you commit, there's no easy way of backing out of the merge when things go wrong (which does happen from time to time) so you can start again.

This can be especially handy if you get a merge conflict with Feature A, and want to ask the developer that worked on Feature A something about it, but he's on his lunch break. With your first workflow, you can abort the merge and just carry on until that developer is back and you're ready to merge again. With the second workflow, you just kinda stuck and have to go find something else to do (or make another clone of the repository and work in that one until you can merge, but that seems worse to me).

Answer 3

This won't work:

• work on a feature
• pull -u
• if branch
  • merge
• commit -m "Worked on feature ABC"
• push

If you have local changes, you may not merge. What you /can/ do is this:

• work on a feature
• pull -u
• work on a feature
• pull -u
• work on a feature
• pull -u
• ...
• commit -m "Worked on feature ABC"
• push

You might also want to investigate hg fetch, it's a shipped with mercurial optional plug-in that does the pull/merge in the same step. Which is good for if you forgot to pull before committing.