Hacker News Reader

Comment by gizmogwai | Hacker News Reader

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.

View on HN

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.

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/

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.

Reply on news.ycombinator.com