The team I am on uses git because we want clean and linear commit history. This means "master" and private branches are very different: - private branches hav

The team I am on uses git because we want clean and linear commit history. This means "master" and private branches are very different: - private branches have lots of random commits which no one will care about once feature is done: "start on feature", "fix typo", "add test", "fix feature", "add interface to foobar", "fix a bug", "fix it for real", "add another function to foobar interface".. and so on - "master" has a nice, clean history. The corresponding commits would be : "add interfaces to foobar", "add feature" This means the developers are actually expected to squash/merge/reword their commits before submitting to master. The submit scripts also enforce ff-only merges, so the master is fully linear. We like this workflow because it has advantages of both SVN -- linear, easy-to-read history, and of git -- you can commit as often as you want and you can share your work easily. Now, we have users struggle with git periodically, but it looks that trying to use Mercurial in our workflow will be even worse -- most of the Mercurial references seem to disapprove of rebasing in general. Example: http://stackoverflow.com/questions/2672351/hg-how-to-do-a-rebase-like-gits-rebase http://stackoverflow.com/questions/2672351/hg-how-to-do-a-re... I understand that this is somewhat unusual workflow; but it illustrates the power of git. You can have a huge variety of the workflows, while Mercurial (and many others) push people towards a single preferred one. And sure, modern hg has "rebase" and "histedit", but they just seem like second-class citizens, and they are much less polished than git's (for example, histedit's man page says " If you drop a change, it's gone forever". Scary! I think I will just use git instead)