A much better UI. Git won because of the influence of the Linux kernel developers, that's all.
Most Windows users, sadly, are simply too backward to use anything that isn't tightly integrated into the Microsoft ecosystem. So, it never really helped Mercurial that much.
GitHub, however, was what drove git.
Unfortunately, Github is to source control as PowerPoint is to presentations. It works--but it's a dumbed-down default and nobody thinks about the fact that there are sometimes much better alternatives for your use case.
Powerpoint is optimized for marketing and not much else. It exists because of two reasons:
1) Most people actively suck at presenting something. Forcing them to put their presentation in Powerpoint-standard forces some level of organization on them.
2) A lot of business presentation IS marketing--and Powerpoint is fine for that.
The problem is that a lot of technical communication really doesn't fit into Powerpoint-standard (see: space-shuttle disasters for example). The problem is that now nobody knows how to do anything else and never even thinks about doing anything else.
I'm a big fan of chalk talks for anything mathematical. I find it hard to stay engaged with slides, even if the presenter uses tricks like revealing one step at a time, annotations, etc.
This is a version control misfeature/bad practice.
It's almost the single version control system that has it as part of its regular commands (though others allow it, generally as part of an admin set of permissions and usually with super clear warnings not to do it).
And it's far from a reason why git won. Git won because it was written by Torvalds and every script kiddie dreams to be a Linux kernel hacker and because the Facebook for Code, Github, took off and it was based on git.
Heck, I'd "accuse" you of rewriting history right now :-))
I remember the GitHub team investing huge amounts of effort into convincing people to use git and teaching them how to do it - one of the four co-founders (Scott) was dedicated to that effort full-time.
I started using git when I was working on embedded Linux professionally in 2005, witnessing the whole bitkeeper saga. I am keenly aware of the history of DVCS 15 years ago.
Meanwhile outside the bubble of academia and startup web devs in 2008, Windows was still by far the most widely used dev platform. I typically deployed Mercurial when I wanted to convince a wider technical audience others of the beauty of DVCS.
GitHub felt safe the same way Instagram (among many) felt safe deploying for iOS only, even when then Android had a larger user base. There are other factors at play, and it was not that git had some kind of major advantage in 2008. If anything mercurial had a slight edge. But if anything in 2008, the wider DVCS market was still in its infancy.
By the time they had addressed some of those gaps, almost all of the projects I used had moved to GitHub, which seemed to be far more of a driver than Linux.
Took a bit to dig up with Google their 2011 announcement that they're now also supporting Git. https://bitbucket.org/blog/bitbucket-now-rocks-git
(Microsoft worked around git by shimming a fake file system driver below the local repository to make it scale enouth to cover the Windows codebase. It's all Windows exclusive and not part of git, so it doesn't really count).
I mean, like, it kinda did in some ways? I feel like GitHub's semi-centralized web UI and pull requests empowered a lot of people to engage in software development online that wouldn't otherwise. I think if it didn't, we wouldn't see value in GitLab and Gittea providing GitHub's accessibility in a more decentralized way.
A lot of software development got a lot better. Yes, software development was possible before GitHub, but it lowered the barrier to entry a lot.
hg added stuff to match git's workflow but it isn't hg's default. The tutorials for hg all teach a decidedly inferior workflow to git.
ps: did a 20 person year long project in hg first, next project was git. Not going back if I can help it.
Curious as how it's "better". I have in all honestly only ever used git.
I'm probably going to be wrong/off on some stuff, but this is what I remember from the old days:
* Mercurial had a better CLI by default -- it was closer to SVN, which made it easier to use, and it was designed so that you had one command that did one thing, whereas git was more flexible but you needed to remember a lot of option flags. * Mercurial had better early GUI client support (this changed, but early on, I know this was a draw for me as a Mac user) * I'm pretty sure Mercurial had better Windows support (I didn't use Windows so I can't speak to this, but I seem to remember this) * Better documentation
But git has evolved a lot over the last decade plus. Not only did GitHub really change the game by creating a more social layer on how to contribute/use git (and yes, I realize GitHub != git, but it definitely helped introduce a lot more people to git), it had features that really honed in on some of the pain points git had compared to Mercurial.
Although BitBucket was sort of positioned as a GitHub for Mercurial solution, it never achieved the organic/viral adoption of GitHub. And when Atlassian dropped hg support last year, it was pretty much confirmation that git "won."
Other than Facebook, I can't think of any major companies that use Mercurial or major projects that use hg.
I used to be sad about this, because I felt hg was better designed, but I came to terms with the reality a long time ago. It is what it is, and version control is often something that network effects define. Use whatever you want for your projects, but git won.
Now, I'm sure there are antsy git users in this forum ready to reply about how great the staging area is because of `git add -p`. I would note that you can also do those things in Hg if you want. For example, the `shelve` command in Hg is analogous to `git stash -p`. If you want to commit only part of the changes you can shelve away the things that you don't want to commit for now. One thing I like about this workflow compared to the staging area is that if you run your test suite, the code that is being tested in your working directory is the same one that will be commited.
Or `git commit -a` — and if you're making commits that frequently it'll be in your shell history anyway.
Git's UI is full of little sharp edges like that. You get used to them, but it's just needlessly fiddly to start with.
Exactly like Mercurial, you mean? Try it if you haven't in a while: you have to call “hg add” to add a new file or you'll get “nothing changed” when you run "hg commit".
The reason why neither of them has a default “add everything in the current directory” mode is that this is how you end up with repositories containing temporary files, build artifacts, and secrets.
This is not a good example to base ”much better UI” claims on.
I'm sure it didn't hurt that Torvalds had many years of experience dealing with lots of the shortcomings of different version control systems and their shortcomings in what is probably one of the more extreme version control situations, and is also known for optimizing the hard parts of things.
It was really the perfect storm for good open source software. A highly skilled developer with massive amounts of domain experience that is highly motivated to solve the problem. What you often get in those situations is something that is an obvious step up from the status quo, at least of free offerings, and often matching the paid offerings if they are more advanced. If it wasn't Torvalds, it just would have taken longer to take over.
It wasn't developed in a vacuum. And there were several interesting distributed open source version control systems around at the time. After moving on from CVS and Subversion, I tried using Arch (tla) for a project. It was interesting, but still tied to the old way of thinking of version control as a series of deltas, both in its conceptual model and in its storage implementation. In fact, its storage was a tarball of a "base revision" plus a series of patches. Checking out a branch meant unpacking the tarball and applying patches in sequence. It was distributed, and elegant in its own way, but it didn't make the conceptual leap which Linus took with git.
In contrast, the hash-based blob/tree/commit model of git was groundbreaking. The storage doesn't use deltas (except as an implementation detail--as an optimisation in pack files). Deltas are computed on demand. Operations on and synchronising between blob stores is simple and fast. That one change is what made git revolutionary. It opened the door for doing so much more with the version control system.
Still, others took that step around the same time, and the git interface is not what one would call intuitive. But for various reasons it had the momentum and took the crown. It's not perfect, but it's still an absolutely superb tool.