Git vs Bizaar/Bazaar

I will spit my vodka in your eyes if all you come up with is speed

WTF? If you can't compete on a very important (to me at least) point, you don't want to listen? Git (especially if you use git protocol) is so fast because they first sorted out the basics and design right and then worked on the UI. Git is not just faster but tons of magnitude faster than bizaar.

I used to think that 'speed' is irrelevant in this context but when I started to use Git, I realized how important it is for me as a developer.

Also the stories of learning curve of Git are extremely over-exaggerated. For example, i recommended Git to a darcs user (who was pissed at darcs taking hours do clone a repo) and after three hours he came to thank me for that. I was surprised to see how quickly he learnt it but then realized that if you just give a bit of information how it's different than other VCSs out there before a newbie actually starts to learn/try it, he/she finds his way very easily into the Git world.

Comments

Anonymous said…
Speed of operation was one of the original goals of git. Linus opinion is that if something is fast, and happens immediatly it's easier to use and you'll use it more often.
Anonymous said…
FWIW, http://weblogs.mozillazine.org/jst/archives/2006/11/vcs_performance.html is rather outdated.
Anonymous said…
This is a more recent comparison (linked by bzr folks, so FWIW):
http://laserjock.wordpress.com/2008/05/08/git-and-bzr-historical-performance-comparison/
marnanel said…
When you talk about the protocol of git being designed properly, are you actually sure that it's a protocol issue? I haven't seen any figures either way, but I'd be far more inclined to examine the fact that bzr is written in Python and git is written in C. (Of course there's nothing stopping someone rewriting bzr in C when the feature set is less in flux.)

(You can write "bzr" if you're having difficulty remembering how to spell "bazaar".)
Unknown said…
"For example, i recommended Git to a darcs user (who was pissed at darcs taking hours do clone a repo) and after three hours he came to thank me for that." -- Are you talking about me?? :)
Anonymous said…
You still need to know way too much about how it works underneath the metal for it to be sane choice for any normal human. That all super developers says that it made sense after a while with the invocations because that is how the underlying format is built, that says to me that it's a horrible choice for any arbitrary team that may contain non-super-developers and rather artists, sound people, managers, designers and writers, apart from the normal coders.
zeenix said…
When you talk about the protocol of git being designed properly, are you actually sure that it's a protocol issue?

No I didn't say protocol but the design. Although I recently realized that the git protocol is extemely fast when compared to git over other protocols.

You can write "bzr" if you're having difficulty remembering how to spell "bazaar"

Nah! I prefer to call it Bizaar. :)
marnanel said…
The other thing to remember is that bzr's being written in Python is a deliberate design decision, and I believe, a strength: it is easier to write ad hoc plugins in an interpreted language, and there is a tradeoff between that and execution speed.

And I do not hate git. All these tools have their strengths and weaknesses; none of them are, heaven help us, Visual SourceSafe or anything. I'd be happy to use any of them on a project.
marnanel said…
Nah! I prefer to call it Bizaar.

This may have a deleterious effect on my taking your discourse seriously.
Andy Wingo said…
Ahem. Did you just link to benchmarks from 2006?
zeenix said…
Ahem. Did you just link to benchmarks from 2006?

Yes! Now i changed that to a very new one but how much did that affect my argument?
Anonymous said…
Bazaar beats Git in speed in almost all tests out there, what are you smoking?
Pete said…
I have to prefer the bazaar path of development. Start with the correct "UI" and get merging powerful. Then build the best backed possible for that.

When I see reports of 'git status' making changes to the repository, I get scared.
Unknown said…
The classic technical argument in git vs bazaar was data storage size. Bazaar now uses a variant of the git storage model which is the same as, or often actually slightly more efficient, than git.

The other argument is speed. Yes, early bazaar was very slow. This is for the same reason that you use for git being fast -- they got the basics right first. Bazaar was technically correct first, then they optimised. This is a very sane way of working and one of the reasons why in many benchmarks recent bazaar benchmarks are as fast or sometimes faster than git.
Anonymous said…
Ross: just a simple question then: why take "a variant" of the repository format, but not "the" repository format of git? This would solve all the current BZR vs GIT issues since it would basically mean that bzr and git are just two interfaces for the same file format?
Andy Wingo said…
I believe if you look at the other benchmark from git.or.cz, the slow bzr benchmarks are the same 2006 ones you removed before; the other benchmarks, from a year ago, show bzr to be comparable with git, speed-wise.

So yes, considering that you changed the first benchmarks to benchmark repository size, and the second ones are inconclusive regarding speed, I do think it affects your argument :)
zeenix said…
So yes, considering that you changed the first benchmarks to benchmark repository size,

Oops I copy&pasted the wrong URL. It should be fixed now.

and the second ones are inconclusive regarding speed, I do think it affects your argument :)

Maybe! but see how my blog entry started a nice debate. :)
Anonymous said…
zeenix: the following one seems an even better comparision, including hg. And guess what: git doesn't win all the speed tests, but bzr doesn't win any...

http://laserjock.wordpress.com/2008/05/09/bzr-git-and-hg-performance-on-the-linux-tree/
@s.f.:

Actually git wins them all (with a statistical margin of error for 'status no changes') because you must always add+commit. HG differs the hard parts until a commit. So, in total it's 25s for Git versus 32s for Hg.

But the entire results on that page are invalidated because he didn't flush the disk cache before benching. So 0x90 on that...
Anonymous said…
None of these benchmarks consider repositories with a reasonable history of commits - at least in bzr 1.5, on repositories with a history, bzr log is orders of magnitude slower than git log. (It sorts commits in a special way, so to get an apples-to-apples comparison you have to use certain command-line flags, but even then the performance was poor.)

A whole bunch of performance improvements might come out of the work with the emacs bzr repository, but we'll have to benchmark the performance of bzr 1.6. But there's no point quoting benchmarks where you just import a tarball - it's just silly.
Viktor VAD said…
Hehe, a tipical argument on benchmarks, when if you read through the bzr documentation it says somewhere clearly: it works faster in some operation and slower in another. Do not try to tell me that it is not the same with every software in this World! :)
For me, understanding is priority to speed. If I just cannot figure out in a sec where am I in the branch, then what's the point in speed? :) Of course I am not telling speed is nothing, but for me bazaar is not slower a bit then svn was before I have changed.

All in all, use them both before you decide which one is the best for your work attitude.
zeenix said…
Ikon!
Dude, this is quite an old blog entry that you are replying to. :) The (flame-)war between git and bzr is long over for me since most repos (gnome, kde, freedestktop, kernel, maemo etc etc) have already moved to git.

Popular posts from this blog

Welcome to the virtual world!

clutter-gst

zbus and Implementing Async Rust API