Mercurial: Onward and upward

Key paragraph for us mere mortals:<p>&quot;In my time with Mercurial, I have seen it grow in fascinating ways. These include the concept of changeset evolution coming to life and the announcement of both Facebook and Google choosing Mercurial over Git. The future of Mercurial is that of scalability and because of that, I believe the best days of Mercurial are ahead.&quot;<p>Is it time to give Mercurial another shot? I first migrated from SVN to Mercurial way back when - but after the massive increase in Git&#x27;s popularity I bit the bullet and switched.<p>What does Mercurial have over Git <i>today</i>?

Mercurial was a real eye-opener. Before a friend basically made me try Mercurial, I was using Subversion for managing my private projects, and it was not exactly fun. Especially when I was working on my laptop (netbook, actually, but that is totally OT), away from home, without access to the server.<p>Mercurial made VCS fun. I recently moved on to Fossil, because I do like the integrated wiki and ticket system for smallish projects, but without Mercurial I never would have gotten there.<p>I also like Mercurial&#x27;s hooks. I am not sure if other DCVS support that, but hooks are great. (Fossil doesn&#x27;t appear to have them)

I&#x27;m excited to see improved mercurial support at bitbucket in the near future. While bitbucket&#x27;s support for mercurial goes back many years, mercurial itself has evolved a lot in the meantime, and bitbucket has been focusing more on support for git for several years now. At the very least, I&#x27;m glad they have someone on staff who cares about mercurial so new features don&#x27;t break things for mercurial users.

&gt; The future of Mercurial is that of scalability and because of that, I believe the best days of Mercurial are ahead.<p>That sounded to me like Mercurial has started to carve their own niche after losing the popularity war to git (maybe just my wishful thinking?), and this may have very good outcomes since currently all scalable mainstream vcs choices are centralized.<p>Git developers showed they&#x27;re hardly interested in this area, and Mercurial have had some head start with the contributions from Facebook. I don&#x27;t think anybody would object it if we had a free dvcs that can respond to very high scalability needs without hacking around its deficiencies. This is the point where Mercurial project should reconsider its priorities and even put some of their current priorities into back seat if that&#x27;s what it gets to achieve their new goals with no compromises.<p>My best wishes for Mercurial, go for it!

I love all the new things the mercurial developers are willing to experiment with and try out. It seems the (sometimes maligned) plugin system that mercurial uses makes this easy. It&#x27;s been really interesting to see how our (mercurial developers&#x27; and users&#x27;) ideas about how distributed version control can and should be used have morphed and changed over the years. I remember when mercurial&#x27;s branching recommendation was to have a clone per branch and when we all hated the idea of modifying our history. Now mercurial supports 4 different branching models and has excellent history editing support with commit --amend, rebase, histedit, and changeset evolution. I&#x27;m excited to play with the other new features that are coming.

&gt; These include the concept of changeset evolution coming to life and the announcement of both Facebook and Google choosing Mercurial over Git.<p>Perhaps this is true for Facebook. But I can say that Google most certainly does not use Hg over Git. The Go source code used to be under Hg, but they&#x27;ve recently migrated to git.

I&#x27;m very excited about bitbucket improving their hg support. The blog poster, Sean Farley, was previously working on Kallithea before going to work at Bitbucket. I met him during Pycon. From my understanding, he&#x27;s still allowed to work on Kallithea.<p>I&#x27;m excited about Mercurial&#x27;s future. There are so many great things coming out. New ways to handle branching, shallow and narrow clones, an experimental interface for running hg over a git store...

I started with and loved Mercurial as a DVCS, and it still has some QoL commands that Git requires some hoop-jumping to get at, but ultimately the deciding factor was the inability to permanently delete branches. Since branched dev work would fairly regularly have generic names or the names of the developer working on it, it would always end up being forked and merged instead of branched and merged, which led to a ridiculous number of headaches in our build system.<p>We still use mercurial for most of our repositories just because they&#x27;re dated and not likely to see more than a handful of commits a year, but most of our active development work has already converted to git.

I wish Bitbucket would invest some time implementing 2FA. It&#x27;s 2015.<p><a href="https:&#x2F;&#x2F;bitbucket.org&#x2F;site&#x2F;master&#x2F;issue&#x2F;5811&#x2F;support-two-factor-authentication-bb-7016" rel="nofollow">https:&#x2F;&#x2F;bitbucket.org&#x2F;site&#x2F;master&#x2F;issue&#x2F;5811&#x2F;support-two-fac...</a>

It seems to work OK but monthly releases for version control software scares the heck out of me.

Mercurial user for the past 6 or 7 years here. I cling to Mercurial despite people asking me to move some of my side projects (nothing substantial though) to git and github.<p>I refuse to do that out of principle. I think Mercurial should have taken the place of git as the widely used DVCS. And I try to be THAT change I want to see.<p>That being said, It would be great if someone can get the hg-git plugin to work seamlessly with newer versions of Mercurial on Windows and Linux, so that I can keep using Mercurial even if a project I am involved in uses git.