Hacker News Reader

Comment by chx | Hacker News Reader

git won because of empty hype, bzr was far superior in basically every aspect. Much easier to program with either for plugins or to be embedded, much saner "hide your development commits" model with log levels, much saner command line interface. It's just better.

It's not the first thing to be carried by hype instead of careful comparison.

View on HN

That's simply untrue. Bzr was dog slow on repos with lots of history. It had lots of early users and support from hosting services like Launchpad, Savannah, and SourceForge. I'm certain that everyone didn't migrate to git because of hype. I mean, it's not credible to say the Emacs team stopped using it because it wasn't fashionable.

There were lots of DVCS projects at the time, like arch, darcs, and dcvs. People were running all kinds of experiments to explore the Cambrian explosion of new ideas. Some of them did some things better than git, but git handled most of those things reasonably well and it was fast. We all mostly ended up on git because it was generally the better option. It earned the hype, but the hype followed the adoption, not vice versa.

So in exchange for a little speed we are stuck with one of the most user hostile tools out there. That's not the deal I would have wanted to make. The interface is atrocious as some switches change completely what the command does -- this was partially acknowledged and fixed in git switch but there's so much more, it loses work way too easily and some of the concepts are near impossible to grok. (I did learn git eventually but that doesn't mean I like it. It's more of an uneasy truce than a friendship.)

It wasn't a little speed. Other options were many times slower. I just renamed a large subdir in a large project. `time git status` took 41ms. That kind of speed lets you add all sorts of interactivity that would be impractical if it were slower. For instance, my shell prompt shows whether the current directory is managed by Git, and if so, whether the status is clean. I would never tolerate my terminal being detectably slowed by such a thing. With git, it's not.

There are a thousand little ways where having tooling be fast enough is make-or-break: if it's not, people don't use it. Git is fast enough for all the most common operations. Other options were not.

I think PR and network effects of GitHub definitely played a role in the success of Git over other options like bzr, but you should also remember that bzr had tons of issues. It was slower, there was no index/staging area, there was no rebasing, etc. Mercurial was very good too, but while there were pluses and minuses with all of them, I think there was a _lot_ of careful comparison too. None of them were clearly and in all aspects better than the others.

Reply on news.ycombinator.com