TBH, I prefer Hg regardless. I only use git when forced to to interact with a project on GitHub. As for replacement, I don't think anyone wants that. Two widely used open source DVCSes is a great thing.
I've tried it during the transition from Google Code. It works well enough but it didn't handle orphaned branches (as used by Github pages) well and I had to provide credentials twice for every push for some reason.
I have. TBH it was more trouble than it was worth, and I had some trouble with the initial setup. It was a couple years ago now though, so it's possibly gotten better.
"I consider the CPython switch from Mercurial to git the final declaration of victory."
Really I think it was bitbucket's total sidelining of hg in favour of git. hg features break regularly on bitbucket and today if you visit bitbucket's home page you're greeted with "Bitbucket is the Git solution for professional teams"
I'm not sure. I have the impression some larger organizations that are moving or using monolithic repos are now aligning more strongly towards hg, because it's easier to extend and optimize than Git.
If you look at the outside contributions that both projects get, this is pretty obvious. Hg is getting big changes from Facebook, Google, Mozilla, ...
Maybe the answer to the argument that a paradigm change is needed to unsettle git is simply "monolithic repos".
imho for CPython, the decision was more of the network effect that Github have rather than picking any particular tool or language. I Know Gitlab was also taken into account, and RhodeCode as well which supported Mercurial and itself is also written in Python. I think in there days for large OS projects it's more important to have more potentials contributors rather than sticking to only Python projects. Just my 2c.
Winning and 'being dead' are two things that mean different things to different people.
Git has at least an order of magnitude more people use it, and there is a significant and growing ecosystem around it that mercurial does not have.
Mercurial is not going to 'die' until the developers abandon it; you can still use and install it. Hell, even cvs isn't 'dead', and the last stable release was in 2008.
Mercurial will also continue to 'not be dead' for the foreseeable future, and people will use it for years to come.
...but it is already niche, and will increasingly become so.
Only time will tell, but I'd be shocked if you don't see more big name migrations away from hg over the next year or two.
People are important.
When your project forces them to use tools that don't like or don't know, they go else where. The impetus to change gathers more slowly in companies; but when you see announcements like this, like google code, like atlassian marginalizing hg, like cpython... it's crazy to suggest that it doesn't affect the way people think about mercurial.
I think "won" means that when you are making an argument to introduce a piece of software into your workplace there is a technology that is more widely used. It doesn't necessarily mean that one is better, but there is usually a reason a technology is widely adopted. If you don't fully understand the advantages and disadvantages of similar products then widespread adoption can help with the decision.
Or if Github had added Mercurial support at the same time Bitbucket added Git support (circa 2011?), I do believe that the playing field would be a lot more even today than it actually is.
Mercurial's storage format was broken from birth; it dealt with the concepts of individual files and history on them. Git's storage format was much more basic but more flexible, with the result that it was possible to implement the Git storage engine in different languages (cgit, jgit, libgit) as well as a minimal transfer protocol.
github catered to some of the big open-source names early.
Of course, now that they've "won". They're basically letting the open-source stuff rot. See the recent complaint by quite a few projects about github and lack of support.
This is the problem with anointing a "winner".
Now we'll have to wait for github's replacement just like we had to wait for SourceForge's replacement.
You don't take into account tooling. There're more options for tools which work with git than for hg. Also, git support is usually more stable and better tested.
Except unlike your examples, hg was contemporaneous with git.
Git may have won the network effect benefit but 10 years ago it was not at all clear how it would shake out. Mercurial did gain enough users (and large users) to remain relevant, unlike some of the other options at the time.
Except its not the DCS paradigm that led to git's network effect. In fact, for the vast majority of users they are using it as a de-facto centralized system (on github).
DCS was around before git and did not sweep the tech industry. Just like concurrent check outs weren't the reason cvs took off.
Most would agree that Git's command line leaves a lot of room for improvement (although the manpages are quite good at explaining). But the internal concept is sound.
I find it a bit odd that no-one has come up with a decent GUI or an improved command line tool for Git yet. There's plenty of attempts to supplement Git with extra commands but that's hardly an improvement. There are several implementations of the Git plumbing parts (e.g. libgit2), so making an UI on top of it wouldn't be that much work.
Git was far from the first DVCS though, or even the first open source DVCS. Darcs, Arch, Monotone at least came before. So this does not explain why Git is the most popular DVCS, or why Git is more popular than Mercurial.
Well yes, that's the point! It would have never been the replacement for git because it's the same paradigm.
No, it really isn't the point. How can hg "replace" git, when they were be developed at roughly the same time for roughly the same purpose (replace bitkeeper, provide a DCS for open source work), with roughly the same model.
Git didn't come up with the paradigm, and neither did hg.
git and hg were direct competitors, not different generations of revision control like the list given.
I think the big big points for git initially actually were: 1) performance - everything comparable but open was way slower back then
2) a usable and relatively small per-checkout history
In the cvs & svn days I used a fair amount of hacks to get those two, and pretty much always failed. For svn svk was a partial solution. For cvs there was rsync, but also something else I can't even remember. Bad memories fade.
svn eventually got a fairly hacky answer to merging edits to a renamed file. For a long time it didn't even try, and git was a godsend compared to straightening out messes like that.
If people would judge a tool on its technical merits, that may be true. However, a lot of people that adopted git hardly needed/used git's improvements (in their one man projects).
hg-git[1] lets hg interoperate with git repositories, which helps a bit with the network effect problem. I'm currently using hg-git for my projects and I am loving it because I much prefer the hg UI (both the command line and tortoiseHg) to git's UI.
I use this constantly --- I've been migrating all my projects to github. hg-git Just Works (almost; there are a few places where the git model doesn't match up with the hg model).
If you like hg, but want to exploit git's network effects, I strongly suggest checking it out.
hg came before git, you have your network effect backwards.
The reason git ended up overtaking mercurial is because git is more flexible. Programmers for closed-source enterprise projects worldwide flocked to git because git can be massaged into any existing development process almost painlessly.
Mercurial, in contrast, is "opinionated".
(Before you mention github -- the timeline here is also backwards, github became the de-facto standard riding on the coattails of git's success.)
I'm curious what makes you say that. From my point of view the exact opposite is true. Mercurial allows many different workflows (bookmarks, anonymous heads, named branches, topics), but with git you're pretty much stuck with the "standard feature branching" workflow.
> Mercurial allows many different workflows (bookmarks, anonymous heads, named branches, topics), but with git you're pretty much stuck with the "standard feature branching" workflow.
Mercurial is internally more complex than Git, as shown by the concepts you mention (bookmarks, named branches, etc) and all the various extensions. By contrast, Git is just a malleable graph of patches and tools to manipulate it. This is very well explained in the first commit(!) of git, which explains the concepts and the internal database layout.
In Git, there might be a "default workflow" that the tools are geared towards but you can use rebase and cherry-pick and all the other tools to enable just about any workflow you can imagine. Of course, this allows you to turn it into a big mess and there are some weak spots (like tracking a lot of bugfix commits backported to several release branches) but the concept is simple and sound.
It's ironic how many people claim that Mercurial is simpler, when actually git is much simpler and more elegant. You don't need named branches, bookmarks, extensions, and all that stuff. Just a graph of commits. The core of git is beautifully simple.
I don't know what's more frustrating-- people who think DVCSes need to be really really complicated, or people who endlessly complain over what color the command-line bikeshed is painted.
git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).