It has greater extensibility (both in protocol and the code itself), which is why Facebook and Google are looking at it in the first place: it's possible to hoo

It has greater extensibility (both in protocol and the code itself), which is why Facebook and Google are looking at it in the first place: it's possible to hook into it in such a way that you can make it scale to ridiculous sizes (see e.g. https://bitbucket.org/facebook/remotefilelog https://bitbucket.org/facebook/remotefilelog) cleanly, in a fully backwards-compatible way, without forking the product. So it's worth looking at for at least that reason alone. Beyond that, though, the team itself is leveraging that extensibility to continue to evolve Mercurial in new directions. Years ago, I was able to ship a third-party largefiles extension that worked similar to the GitHub external files thing launched a few weeks ago, and was able to get it integrated into Mercurial easily, where it was heavily used for years by people in the games industry. The team took "bookmarks" (Git-style branches) under its wing when they proved valuable, and have now added a ton of behavior to improve bookmark workflows. They can even add huge new features. the big one that Git lacks is changeset evolution. Evolution allows you to get all of the benefits of rebasing and squashing, and all the benefits of a traditional DVCS merge-based workflow. Specifically, you can see all the previous versions of a given changeset, but those versions don't need to clutter up the history unless you're specifically interested. This means you're dramatically less likely to lose critical forensics information over the course of developing a new feature, and much more likely to be able to sanely see where, over the course of several rebases, you mucked up how a chunk of code actually worked.