Hacker News Reader

Comment by Aqwis | Hacker News Reader

Oddly, both Bazaar, Git and Mercurial were created around March/April 2005. Why the sudden appearance of popular DVCSs around that time, and why did Bazaar fall behind the other two in popularity?

View on HN

All of them emerged due to the end of license agreement for a free license of bitkeeper for the linux kernel. Git won due mainly to Linus personnality and the rise of "social coding" via github. Bazaar failed because, at the beginning, it was painfully slow compare to git and mercurial. It speed has increase over time, but bad reputation is hard to get rid of.

All of them emerged due to the end of license agreement for a free license of bitkeeper for the linux kernel.

Bet bitkeeper regretted that decision...

If I recall, the zeitgeist then was that bitkeeper was a necessary evil. My guess is that git would have come into being eventually in any circumstances short of bitkeeper becoming free software, and maybe even then. Distributed change management is such a critical component of the kernel development process (especially for Linus and the other maintainers) that relying on someone else's software seems suboptimal.

The reason Bitkeeper dropped the kernel was that certain kernel devs had started writing free software to interact with the kernel repository (they wanted to be able to perform certain tasks that bitkeeper couldn't). Had this continued, we would probably have ended up seeing a free version of Bitkeeper.

They don't seem to have updated their website since http://www.bitkeeper.com/

I'd say git is popular not just because of Linus, but also because it is oriented towards "just getting stuff done", rather than towards theoretical concepts.

You can rewrite history, fix your mistakes, and generally do whatever you want. When merging, git isn't picky, either: if the code looks the same, it is the same.

In-place branching is hugely useful, just switch your tree in an instant (your editor should update the contents of your files automatically). So is the stash. Overall, it's just a useful tool that doesn't try to teach you "how things should theoretically be done", and never says "well in order to get X, you should have done this a long time ago".

Except bzr is conceptually easier to learn and has a more consistent command syntax than git.

What are some of the conceptual differences that make bzr easier to learn? (I agree that git's command syntax is inconsistent.)

Command names are closer to SVN/CVS ones, which lower the learning curve for similar concepts. The documentation really is at another level of didactic compare to git, and no, pro-git is not enough neither. Changes are tracked automatically, no need to explicitly add the files you changed to a particular commit (Whether or not it is a good idea is another discussion). Empty directories can be versioned, no need to create a .gitignore in it to fool the system (Same remark as above).

The syntax is part of it being easier. Also, though it's been a while since I tried using any official git documentation, bzr's website had handy tutorials, references, and cheatsheets available. Great layout, assumed no VCS experience.

That's not conceptually simpler, that is just easier to learn. Git's concepts actually are simple. You can explain the concepts and guts of git to developers with a whiteboard in a few minutes.

The standard CLI UI is admittedly a weak-point, but it does not appear to have slowed adoption...

I get what you're saying, but it depends on how you learn it. I tried learning both of them through their official tutorials and /their CLI commands/. With git's more confusing command set, I had a harder time learning.

Git was by far the fastest, this was a big factor when evaluating the move from svn (or similar) to a new system.

Not at all, early git was way slower than early hg. For some operations, e.g. cloning, got is still way slower.

But most people were comparing it to CVS or SVN, and it was much faster than those.

>> Bazaar failed because, at the beginning, it was painfully slow compare to git and mercurial. It speed has increase over time, but bad reputation is hard to get rid of.

Is this an example that goes against the common advice to launch an MVP fast to test the market (and then keep on improving)? It seems that the advice is valid only when there is nothing for the customer to compare the to-be-launched product to. If competing products end up launching at around the same time as yours, the advice may turn its head on you.

This is a good point. Is there more to this? As a big believer in the MVP, this is something I have to look more into.

Git was also early to the market, but had a fast core and terrible user interface. Git was used for the Linux kernel only two months after Linus had started coding.

Well, as this article implies, a lot of people don't consider bzr's speed minimally viable.

Adding a bit of history to the other comments: Bazaar is actually a successor to an earlier DVCS, called Gnu Arch (or Tom Lord's Arch, TLA, at some point). It started out in 2001 and was, I believe, the first of the DVCS crowd. It had some idiosyncrasies, but was a huge step up from CVS in terms of its principles.

tla was forked into baz (previously Bazaar), and bzr (previously Bazaar-NG) was a rewrite taking into account lessons learned from tla/baz. Darcs is yet another DVCS inspired partly by Gnu Arch.

So while the explosion of new DVCS around 2005 can definitely be traced back to the Bitkeeper incident, I believe the seed for modern DVCS was laid a bit earlier, in 2001, with Tom Lord's Arch. I think Gnu Arch/tla is to be credited with originally introducing many of the concepts of distributed version control.

Of course, if anyone knows of earlier history on distributed VCS or a VCS that isn't in some way a spiritual successor to TLA I would be quite interesting in knowing that.

Here [1] is a good but necessarily incomplete summary of version control tool history, written by ESR.

Tom Lord does deserve much credit for DVCS concepts, but so do Larry McVoy (Bitkeeper) and Graydon Hoare (Monotone).

[1] http://www.catb.org/esr/writings/version-control/version-con...

I'd give Larry McVoy most credit of the three. He worked at TeamWare, which was the first DVCS, at least the first I have heard of. I don't know how much credit goes to him specifically, compared to the other people who worked on TeamWare though.

http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare

One thing that git wins for me is interoperability. git's format-patch, send-email, apply and am subcommands make it very easy to interoperate with others using plain text patches on mailing lists for code review, etc.

At this stage, isn't a "bzr vs. git vs. hg" question at all. It's just "look, it's a patch".

I think this ease and ability to work losslessly with plain text patches gives git a clear advantage over bzr.

This functionality makes it really easy for people who don't know git to interoperate with people who know it.

Lossless interoperability with plain text is a key Unix principle (see TAOUP) and something that bzr lacks.

With bzr, everybody involved with a project must use bzr. OTOH, a project that uses git can work more easily with a whole spectrum of people since sending a simple patch to a mailing list provides exactly the same ease of workflow to git-using developers as a complex multi-stage set of changes that is heavily reviewed and modified before being committed.

(I don't know hg well enough to understand how it fits in here)

I'm entirely ignorant of bzr, but I've got to say that this surprises me. We use svn, which certainly works well with patch.

To the extent that svn works with patch, so does bzr, and so does git.

What I'm talking about is lossless integration with entire patch sets in the form that git does it with format-patch, send-email and am.

git patch support is more feature complete. Atomic application by default and using parent information for three-way merge to apply patches if requested.

Git won the popularity war because the Linux kernel used it and then Github pushed it mainstream. Frankly, Bzr never got as popular as Git and Hg because it just isn't as good. It's slow, has a bizarre (sorry) branching model, and came out of Baz and Arch which were downright terrible (to be fair, Bzr shares no code and was designed as a rewrite to jettison all the stupidness of Baz and Arch—nonetheless it is tainted by being related to them).

Actually I think Github got popular because it was Git, not the other way around. At the time it appeared people just wanted to have git repos, Github was there, so they used it.

Confirming that, Bitbucket added git support because they saw Mercurial as not competitive with Git.

But only after Git became wildly popular because of GitHub.

There wasn't a demand for Git repos any more than there was a demand for Hg repos. For instance, open source projects moving away from SVN seemed to be pretty evenly distributed between Git and Hg.

The real demand was for a way to publish code and collaborate, and GitHub provided a truly innovative approach (the social aspects, encouraging forking and pull requests) that was miles better than the alternatives (SourceForge was already in decline, Google Code didn't have the social/forking/pull request aspects). I think they would have been successful with any distributed VCS. I always preferred Git, so I'm happy they chose Git, but I think that if they had chosen Hg, we'd be talking about how Hg won the popularity war instead of Git.

This is what happened, basically a huge "I told you so, proprietary software blows." for the Stallmans of this world: http://www.theregister.co.uk/2005/04/14/torvalds_attacks_tri...

This is excellent trolling material because you can argue in both directions: It proves proprietary software can't be trusted; and at the same time it proves Open Source is all about free knockoffs of innovations made in proprietary software.

I think it was due to the free version of bitkeeper (which the Linux kernel used for vcs) was taken off market. So the Linux devs would either have to pay for a DVCS or make their own... Several made their own, Git was chosen for the kernel, alot of people found uses for the others. I could be wrong, but I think that's the case.

There never was a free version.

BitMoover Inc provided free BitKeeper licences to the Linux kernel devs. This was unpopular because of the non-FOSS nature of Bitkeeper. Andrew Tridgell [1] at OSDL became frustrated with some aspects of the software and reverse-engineered its network protocol to develop his own limited client. This caused BitMoover to revoke the licences used by OSDL, which in turn provoked Linus Torvalds (who was at OSDL) to develop the early version of Git. [2]

[1] http://en.wikipedia.org/wiki/Andrew_Tridgell

[2] http://en.wikipedia.org/wiki/BitKeeper#Pricing_change

In 2005, there were already some free, open-source DVCSs. Linus considered using Monotone for the Linux kernel project before deciding to start Git.

git is used by a bigger project (the kernel), that's mainly why. they're all ok, otherwise, even with their technical differences.

github also contributed to amplify the adoption as its makes it really easy to use (even thus people generally use git in a non-distributed way with github)

(i do prefer git in usage, tho, but thats subjective i suppose)

for me it's the easy branching and rebasing that make git the winner. That's in spite of the inconsistent cli.

If Hg were as good at branching and rebasing, I'd reconsider it.

btw, anyone know of a python command line client for git? I just keep finding stuff for programmatically using git and that's not what I want.

What do you mean, a python command line client? If you're using it from the command line and not programmatically, why does it matter what language it's written in?

(gitless may possibly be what you want)

It matters if you want to hack on it.

portability

http://www.samba.org/~jelmer/dulwich/

Thanks!

And Xorg, and Samba, and Wine, and a bunch of other projects. In retrospect, people overestimate github's impact, I think. "Fast enough for big projects like the kernel" was a big deal.

Cambrian explosion followed by consolidation.

Git and Mercurial were Linux affiliated.

In the end, when apps are similar and don't have fatal flaws, it comes down to a popularity contest.

> Cambrian explosion followed by consolidation.

The term is "adaptive radiation", of which the Cambrian explosion is a prominent example. (Unrelated but awesome note: search for "edicarian biota" to look at some body plans that might have won, but didn't.)

If you read the article included in the post it says that git, mercurial and bazaar all came together because Bitkeeper stopped being free. Now as for why bazaar didnt get used so much even when supported by canonical is a mystery to me.

I'm surprised he didn't mention GitHub. You can't ignore the luck that the guys that made GitHub used Git.

people need just one DVCS. it was slow and when it finally got fast, it didn't matter, because everybody was happily using the alternatives.

Canonical mismanagement, contributor license agreement, missing manpower.

The article and the quite detailed bzr history it links to do not appear to suggest this at all. Can you provide any justification for your three claims?

License Agreement: the first paragraph in the section "Hard to land patches" describes the CLA as one reason why it's hard.

Missing manpower: just glance at the mailing list archives.

Actually, sources for all three statements can be found within 2 paragraphs (moving forward and backward) of "Decline and focus on Ubuntu and UDD"

Reply on news.ycombinator.com