4 ms·
I'd argue that GH won over Bitbucket because of two key factors: 1. It wasn't developed by Atlassian, who at the time had a reputation for building more unwiel
by indrora 4y ago
I'd argue that GH won over Bitbucket because of two key factors:
1. It wasn't developed by Atlassian, who at the time had a reputation for building more unwieldy tools (Jira, anyone?) and had a weird, awkward feel. The fact that Git had gained near instantaneous traction and Bitbucket needed you to learn Mercurial made it a near non-starter.
2. GitHub's model ("Social Coding") and zero-effort force amplification made it just the right wedge. Git had terrible tooling on the frontend and GitHub providing "Just enough" tooling around the server side while also providing the right kinds of tooling (webhooks, enterprise-ish features, click-to-fork, a very good PR path, etc) made it easy to use Git.
Mercurial might be the "superior" tool from certain standpoints but Git had a few tricks up its sleeve that made people like it:
* Written in C. No extra runtimes.
* Modular construction: `git-slap` is immediately available as `git slap` like a native tool.
* Performance of Mercurial was bad on massive codebases and slower machines. I mean terrible. once you hit 500KLOC or into the 2MLOC, a simple merge could take minutes if not tens of minutes in the old days if you weren't on a fairly modern (2005-7ish) machine. If you'd kept your slightly older P2 laptop around, you were absolutely roasting under the weight of what took Git mere seconds.
- i_like_apis 4y agoMercurial performance is still terrible for large codebases.
- skinnymuch 4y agoSomeone said it is their job to keep HN a nice place. I will try to follow suit. Could you provide citations or evidence to such a claim? In following HN guidelines, I did not do a quick dismissal. I spent time and ran tests. I do not see the same conclusions. I am ready to post up some data in good faith.
- i_like_apis 4y agoI work with (a fork of) Mercurial + a huge codebase. Checkout and merge operations in a local repo frequently take minutes. Perhaps there is something I don't understand going on, or perhaps it is the age of the fork. But I don't think so it, because I think it would have been fixed. > I spent time and ran tests. Ok? Share 'em. The scale I'm talking about is ginormous though. (Roughly: multiple GBs, 100k+ files & probably 250k+ commits in history). For all I know it could be state-of-the-art performance for the scale, but repeat tasks taking minutes is still bad news.