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.