Usage discussion from the GNU Emacs project.

Jason Earl jearl at
Thu Nov 26 21:35:57 GMT 2009

"Stephen J. Turnbull" <stephen at> writes:

> Jason Earl writes:
>  > Over the past year I have gotten a little bit tired of hearing
>  > about bzr's poor performance.
> Heh.  Just wait until people start really using it.
>  > This is especially true when I believe that git's supposed speed
>  > advantage is only imagined, and not actually measured.  I've
>  > checked out the Emacs repository using git on a regular basis for
>  > the last year or so, and I did not remember this feat ever taking
>  > less than 20 minutes.
> I'm curious about your hardware and network connection.  I'm using a
> MacBook Pro (Mac OS X 10.5.8, 2.4GHz Intel Core 2 Duo, 2GB 667MHz DDR2
> SDRAM) connected via KDDI ADSL (aka Son of International Telephone and
> Telegraph of Japan).  The software is from MacPorts:

My network connection is 15Mb Fiber.  My hardware, on the other hand,
tends to be very anemic.  In the tests in question it was a 1.2GHz
single core AMD processor of some stripe with 1GB ram.

With a little testing on faster hardware it has become clear to me that
git (with the git protocol) does extend its lead against bzr's dumb
server on faster hardware.

> wideload:webdeveloper/development 10:10$ port installed git-core bzr
> The following ports are currently installed:
>   bzr @2.0.1_0 (active)
>   git-core @ (active)

My bzr version is whatever comes with Ubuntu 9.10 and my git version is (although I did test with a git pulled from the git repo).

> git using the git protocol is (just) under 8 minutes from
> and under 8 minutes from Savannah.  That's a long coffee break.  bzr
> using http is well over 28 minutes from Savannah, which is plenty for
> a quick lunch.  Full data at the end of the post.

In other words, since this is something that is only going to happen
infrequently (once per machine you hack on) you just spent more time
writing this email than you would have saved assuming Emacs were to
switch to git :).

And, as you pointed out, you can go to lunch while doing your first bzr
branch (or read your email, or play nethack, etc.).

What's more, you aren't even really benchmarking something the bzr
hackers are likely to fix, ever.  Pulling in bzr with a dumb server is
already faster than using a dumb server with git, and from my own tests
I can pull from a smart bzr server (including checking out the sources
on my anemic machine) in ten minutes.

This isn't really about git vs. bzr, its about savannah with git and

Although I will say that branching from a smart server does take quite a
bit of server resources.

> The comparison git: vs http: would be unfair, except that it is not
> clear when Savannah is going to get around to implementing either SSH
> access or a smart server (or a repository browser, for that matter).
> They do not seem to be excited about either.  Worse, it is apparently
> not something they can do on a project by project basis, so the more
> bzr use they see, the more reluctant they will be to take all the
> projects down to make the switchover.  (Neither rms nor Stefan seems
> to be willing to go to the mat on this, either, so it's entirely up to
> the goodwill of savannah-hackers -- which according to the page posted
> by Karl is present, but small.)  But on the contrary, git's smart
> server is already running and the repo browser is working.

It is ironic that savannah has better git support than bzr support.

The FSF can be a really interesting organization sometimes.  Now that
the launchpad code is free software I wonder if RMS could be talked into
using to host Emacs development?

Yeah, probably not.

> Note that the head-to-head comparison is easy to make, and there are
> plenty of git users who are going to notice because they'd rather use
> git in the first place.

The git fans are going to complain.  That is essentially inevitable.
You are being a good sport about the switch (including writing
documentation) but *you* are going to complain.  If the best they can do
is complain about how long it takes to check out the first branch then
they can safely be ignored.  If worse comes to worst a premade
repository can be downloaded in less time than it takes git to cough up
the sources for the first time.

Bzr really should automate this.  There should be a --first-time flag
that doesn't try so hard to be smart.

As I pointed out in the email to Óscar bzr has other problems that are
likely to be better candidates for complaint.

>  > The moral of the story is that if you are getting the entire
>  > history of the Emacs project it is going to take a while, and using
>  > git doesn't necessarily help.
> Not for you, but it helps a lot for me.

Yes, as I said better hardware does seem to extend git's lead (assuming
you have access to a smart git server).

>  > And if you think bzr's progress indicator is bad you should see
>  > what git's http progress indicator looks like.
> Not relevant, because bzr's progress bar can clearly be improved (and
> it wouldn't be hard.  Here's what I think bzr's progress bar should
> look like:
> (\) [ 123MB | 100MB/s ] Please contribute an attractive progress bar!
> or how about
> (\) [ 123MB | 100MB/s ] Your ad here!!
> ;-)  And the rate should be total bytes/total time, not instantaneous.  

Genius.  The ad for a new progress bar would be perfect, but just
changing to bytes/total time would help a lot.

>  > And either way bzr is much better than cvs.
> Again, the git fans on emacs-devel are *not* going to compare to CVS.
> Telling them to do so is just going to convince them that Bazaar
> doesn't want to respond to performance issues.

Yes, and RMS is only slightly more likely to change his mind on this
particular issue than he is on his choice of text editors.

Git fans are very loyal, and with good cause.  If you can learn to use
it, you have a pretty good system.


More information about the bazaar mailing list