Tbh, I don't even know if it is true today. Circa 2008-2010, I think Mercurial was certainly better -- it was certainly better designed and easier for a newcomer to use.
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.
One thing I prefer about Mercurial is that it doesn't have a separate staging area. To create a new commit in git you need to run `git add` followed by `git commit`. In Mercurial it's just `hg commit`. Furthermore, if you want to look at the diff in git sometimes it's `git diff` and sometimes you need to run `git diff --cached`.
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.
> Except that if you added a new file then "git commit -a" will miss it out.
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.
So everything that you modified since last commit will get committed regardless? I can't add logging to some file or manually override a config without it getting it committed as there is no staging? Doesn't sound like much of a selling point, unless I'm misunderstanding...
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.