Is `hg pull --rebase` analogous to `svn update`?

Question

This question assumes there\'s a \"blessed\" central repository that members of a team

1. clone from
2. push to when they have contributions that they want othe

Answer 1

As others have indicated, almost but not quite. In order of decreasing similarity to svn update (and increasing compliance with general DVCS, and specifically Mercurial, best practices[1]):

1. hg pull -u (or hg pull followed by hg update) with your changes uncommitted and no committed changes since your last pull. This is as close to svn update as you can get, but is pretty bad DVCS practice. One of the niceties of DVCS is that you can commit your changes before trying to merge them with others, and thus have a backup version to rollback and retry a failed merge, and this practice gives that up. Don't do it.

2. hg pull --rebase after committing your changes. This pulls the upstream changes, re-applies your changes on top of them, and lets you push your changes back as a linear history. The end result will look very similar to a Subversion revision history, but you get the DVCS benefit of committing before merging. I do not know how the safety of this mode of operation compares between Mercurial and Git, though; in Git, pre-rebase versions of your changes will still be there until you do a git gc, but Mercurial doesn't have an explicit gc safety net.

3. hg pull followed by hg merge with your changes already committed to your local copy. This is the traditional Mercurial practice for doing the functional analog of svn update, notwithstanding footnote 1 below. This results in a nonlinear version history, but all changes are tracked and inspectable.

That said, there is much wisdom in thinking of Mercurial (and other DVCSes) on their own terms, and not trying to translate from Subversion/CVS-style thinking.

1. If you are not of the rewrite-history-to-keep-it-linear school of thought. If you are, then rebase is probably preferable to update. The Mercurial community tends to favor update.