hg could be 20% better than git. For the sake of the arugment, let's say it is.
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).
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).
less is more, in this case. :P
I still have to understand how CPython could miss the symbolic meaning of this decision.
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"
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".
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.
Also it's not true that a lot of forward-thinking, progressive, thought leader tech companies are using Lotus Notes. That is true of mercurial.
http://alblue.bandlem.com/2011/03/mercurial-and-git-technica...
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.
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.
rcs: revision control
cvs: concurrent check outs
svn: atomic versioning (edit: originally said renames that don't suck - thanks Danny for correcting this)
git: decentralised version control
To replace git, you need a new paradigm. I don't know what it is, and I think few people here would.
Edit: to reiterate, none of this has anything to do with whether git or hg is technically better.
DCS was around before git and did not sweep the tech industry. Just like concurrent check outs weren't the reason cvs took off.
um.... how about a good command-line UI that doesn't require remembering all sorts of crazy command line switches?
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.
No, it was "atomic commits and single revision number for a change"
Remember CVS had non-atomic commits (part of the commit could succeed, part could fail), and per-file version numbers.
Disclaimer: I worked a lot on SVN :)
Well yes, that's the point! It would have never been the replacement for git because it's the same paradigm.
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.
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.
If you like hg, but want to exploit git's network effects, I strongly suggest checking it out.
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.)
The experience of migrating to DVCS's. (Anecdotal, I know, but still...)
>...but with git you're pretty much stuck with the "standard feature branching" workflow.
Git is a loose collection of file manipulation utilities, it can be cobbled together to support even the most insane workflows.
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.
Can you explain? Not sure how hg being released earlier changes how many users they have. See https://en.wikipedia.org/wiki/Network_effect
GitHub and Linux gave git the network effect.