4 ms·

What I still can't believe is that the world chose git over hg. Why would you use git if you could use Mercurial instead?

TeeMassive 5y ago
- Speed - The fact that it was Linus developing it - The fact that it was released just after Git - It's pretty much like Git and evolved to be usable like Git - Git had way more advanced tooling and still does to this day
- quleap 5y ago
  > - It's pretty much like Git and evolved to be usable like Git > - Git had way more advanced tooling and still does to this day Very untrue. Mercurial has advanced concepts and features that Git cannot dream of, e.g. changeset evolution.
arantius 5y ago
For me: `git gui` and the stage. Incrementally building my commits line-by-line (often with other working directory changes I don't want) feels invaluable. Work forced me to go git->hg and it frustrates me every day.
krallja 5y ago
Basically, GitHub. GitHub would have won even if it were MercurialHub. It had a better user model of the problem to be solved than any other SaaS code forge, and it supported both open-source bazaar-style development and private enterprise. The gamification and social network features are KILLER. Also, the Mercurial developers never had the built-in fan base of Linus Torvalds. Anyone who wanted to work on Linux had to use Git, so that was another major reason to learn (and stick with) Git.
- adamrezich 5y ago
  imagine "SubversionHub" instead...
  - whynotmaybe 5y ago
    SourceSafeHub...
  - xxpor 5y ago
    that's sourceforge :)
- tapan_jk 5y ago
  > Basically, GitHub. This. Which basically means: no time to setup, no operations overhead, no administration required. This means, no dedicated team member needed who is the "admin" for version control, no dedicated infra required, etc. In the early 2000s when we were a team of 8 developers, one was a "ClearCase admin". He was a single point of contact for all things ClearCase (request him to create a new branch, add a new user, create a label, create a new repository and so on). He also had to ensure regular backups were done, the server was regularly patched, the disk had enough space. GitHub/Gitlab simply remove all of this just for a few dollars per user.
  - stickfigure 5y ago
    While I can identify with the ClearCase/Perforce/etc admin issue, there were a multitude of code hosting solutions that predate GitHub. Google code supported subversion and mercurial; Before that, tigris.org supported subversion; before that, Sourceforge supported CVS.
- dahart 5y ago
  I watched git take over in several companies before anyone had ever heard of GitHub. One reason for Git’s success in my mind is that the actual competition in practice was Perforce, not Mercurial, and Perforce’s workflow and scripting UX and design are stuck in 1997… still! ;)
pacetherace 5y ago
Because Linus created it and Linux community adopted it.
notacoward 5y ago
...or bzr, or monotone, or other contemporaries implementing extremely similar models. Git won because of its author's fame in an entirely different domain; both its use for the Linux kernel and the existence of GitHub are secondary to that.
mhitza 5y ago
It's been ages at this point since I used Mercurial (around 2010) and probably these things changed along the way. - But with mercurial branching where more like forks with different directories. Made me avoid that feature in web development work (that way I didn't have to fiddle with my webserver config every time I would have liked to create a branch) - I recall having to deal with a bunch of gotchas around mercurial bookmarks (tags), like not being able to delete them, problems with sharing them with others, and things like that. I was actively exploring different DVCS around that time, coming from a SVN background where I remember spending a lot of time fixing merge conflicts like a sucker. The one I liked, for its theoretical aspects, was darcs (as I was also leaning heavily in the Haskell ecosystem of the time). Anyway, in short for me git overtook mercurial because it was easy for me to hop around multiple branches, pick off individual commits, and rebase commits (I was still pedantic about how I formatted my commits before a PR, nowadays, not so much).
- andrewshadura 5y ago
  > But with mercurial branching where more like forks with different directories. That's bzr, not Mercurial. Mercurial has always had more advanced branches than Git.
  - mhitza 5y ago
    It's been more than 10 years since I've used mercurial, so I had to try and dig up old documentation (hard to do with my Google-Fu), anyway I've found an older HN post that discuses the separate directory thing back in 2009 https://news.ycombinator.com/item?id=1013320 https://news.ycombinator.com/item?id=1013320 I'm sure a lot has changed in that timespan, and maybe it was a bit more of a nuanced situation wrt branching, but the pain points are the things I can only vaguely recall at this point.
    - andrewshadura 5y ago
      That post may have been discussing it, but it was not based on the reality. Having multiple clones is just one of the workflows, one Git users also frequently employ. If anything, Mercurial’s branching model has always been richer than that of Git, since even when if didn’t have Git-style branches (bookmarks), it supported named branches and anonymous branches, which already allowed for a wider variety of workflows than Git ever did.
mbfg 5y ago
branching is just better in git. sorry. I like Hg, we used it for like 4 years, but switched to git, and have been using it for 10 years now, never looked back.
unmole 5y ago
> Why would you use git if you could use Mercurial instead? Because Mercurial was (Still is?) hopelessly slow on large repositories.
- ezst 5y ago
  not true, for instance, git being slower than hg for things like large monorepos is why google and facebook invested so much in hg (while microsoft has been pretty busy reinventing large parts of hg in git, as git-vfs for instance).
lifefeed 5y ago
Git made it easier to fix problems when I screwed up my repo. Mercurial was great when everything was working correctly, but for a long time it lacked the tools (or required third party tools) to fix problems I ran into. Mercurial did have one killer feature, and that was hginit.com. Git's documentation was terrible for a long time. I would send programmers used to old fashion version control to hginit all the time, even when I was teaching Git.
bombcar 5y ago
I’m going to solidly blame Mercurial for having hg as a command - I couldn’t figure out why mer tab didn’t find anything and moved on.

TeeMassive 5y ago

- Speed - The fact that it was Linus developing it - The fact that it was released just after Git - It's pretty much like Git and evolved to be usable like Git - Git had way more advanced tooling and still does to this day

quleap 5y ago
> - It's pretty much like Git and evolved to be usable like Git > - Git had way more advanced tooling and still does to this day Very untrue. Mercurial has advanced concepts and features that Git cannot dream of, e.g. changeset evolution.

arantius 5y ago

For me: `git gui` and the stage. Incrementally building my commits line-by-line (often with other working directory changes I don't want) feels invaluable. Work forced me to go git->hg and it frustrates me every day.

krallja 5y ago

Basically, GitHub. GitHub would have won even if it were MercurialHub. It had a better user model of the problem to be solved than any other SaaS code forge, and it supported both open-source bazaar-style development and private enterprise. The gamification and social network features are KILLER. Also, the Mercurial developers never had the built-in fan base of Linus Torvalds. Anyone who wanted to work on Linux had to use Git, so that was another major reason to learn (and stick with) Git.

adamrezich 5y ago
imagine "SubversionHub" instead...
- whynotmaybe 5y ago
  SourceSafeHub...
- xxpor 5y ago
  that's sourceforge :)
tapan_jk 5y ago
> Basically, GitHub. This. Which basically means: no time to setup, no operations overhead, no administration required. This means, no dedicated team member needed who is the "admin" for version control, no dedicated infra required, etc. In the early 2000s when we were a team of 8 developers, one was a "ClearCase admin". He was a single point of contact for all things ClearCase (request him to create a new branch, add a new user, create a label, create a new repository and so on). He also had to ensure regular backups were done, the server was regularly patched, the disk had enough space. GitHub/Gitlab simply remove all of this just for a few dollars per user.
- stickfigure 5y ago
  While I can identify with the ClearCase/Perforce/etc admin issue, there were a multitude of code hosting solutions that predate GitHub. Google code supported subversion and mercurial; Before that, tigris.org supported subversion; before that, Sourceforge supported CVS.
dahart 5y ago
I watched git take over in several companies before anyone had ever heard of GitHub. One reason for Git’s success in my mind is that the actual competition in practice was Perforce, not Mercurial, and Perforce’s workflow and scripting UX and design are stuck in 1997… still! ;)

pacetherace 5y ago

Because Linus created it and Linux community adopted it.

notacoward 5y ago

...or bzr, or monotone, or other contemporaries implementing extremely similar models. Git won because of its author's fame in an entirely different domain; both its use for the Linux kernel and the existence of GitHub are secondary to that.

mhitza 5y ago

It's been ages at this point since I used Mercurial (around 2010) and probably these things changed along the way. - But with mercurial branching where more like forks with different directories. Made me avoid that feature in web development work (that way I didn't have to fiddle with my webserver config every time I would have liked to create a branch) - I recall having to deal with a bunch of gotchas around mercurial bookmarks (tags), like not being able to delete them, problems with sharing them with others, and things like that. I was actively exploring different DVCS around that time, coming from a SVN background where I remember spending a lot of time fixing merge conflicts like a sucker. The one I liked, for its theoretical aspects, was darcs (as I was also leaning heavily in the Haskell ecosystem of the time). Anyway, in short for me git overtook mercurial because it was easy for me to hop around multiple branches, pick off individual commits, and rebase commits (I was still pedantic about how I formatted my commits before a PR, nowadays, not so much).

andrewshadura 5y ago
> But with mercurial branching where more like forks with different directories. That's bzr, not Mercurial. Mercurial has always had more advanced branches than Git.
- mhitza 5y ago
  It's been more than 10 years since I've used mercurial, so I had to try and dig up old documentation (hard to do with my Google-Fu), anyway I've found an older HN post that discuses the separate directory thing back in 2009 https://news.ycombinator.com/item?id=1013320 https://news.ycombinator.com/item?id=1013320 I'm sure a lot has changed in that timespan, and maybe it was a bit more of a nuanced situation wrt branching, but the pain points are the things I can only vaguely recall at this point.
  - andrewshadura 5y ago
    That post may have been discussing it, but it was not based on the reality. Having multiple clones is just one of the workflows, one Git users also frequently employ. If anything, Mercurial’s branching model has always been richer than that of Git, since even when if didn’t have Git-style branches (bookmarks), it supported named branches and anonymous branches, which already allowed for a wider variety of workflows than Git ever did.

mbfg 5y ago

branching is just better in git. sorry. I like Hg, we used it for like 4 years, but switched to git, and have been using it for 10 years now, never looked back.

unmole 5y ago

> Why would you use git if you could use Mercurial instead? Because Mercurial was (Still is?) hopelessly slow on large repositories.

ezst 5y ago
not true, for instance, git being slower than hg for things like large monorepos is why google and facebook invested so much in hg (while microsoft has been pretty busy reinventing large parts of hg in git, as git-vfs for instance).

lifefeed 5y ago

Git made it easier to fix problems when I screwed up my repo. Mercurial was great when everything was working correctly, but for a long time it lacked the tools (or required third party tools) to fix problems I ran into. Mercurial did have one killer feature, and that was hginit.com. Git's documentation was terrible for a long time. I would send programmers used to old fashion version control to hginit all the time, even when I was teaching Git.

bombcar 5y ago

I’m going to solidly blame Mercurial for having hg as a command - I couldn’t figure out why mer tab didn’t find anything and moved on.