Emacs Bazaar repository

[James Westby]

On Fri, 2008-03-14 at 14:59 +0100, David Kastrup wrote:
> James Westby <jw+debian at jameswestby.net> writes:
> 
> > On Fri, 2008-03-14 at 14:35 +0100, David Kastrup wrote:
> >> John Arbash Meinel <john at arbash-meinel.com> writes:
> >> 
> >> > The biggest reason 'bzr log' is slow is because we spend some time
> >> > analyzing the ancestry to give a "pretty" view, while git/hg do not.
> >> 
> >> git most certainly does.
> >
> > But it's analysis is different.
> 
> How?

May I point you to my blog post of yesterday that explains some of
these issues, rather than spell if all out here?

http://jameswestby.net/weblog/bzr/01-revision-numbers.html

The last section is on this particular issue.

The gist of it is that topological sorting means that children appear
before their parents. bzr does "merge sorting" that ensures that a
revision does not appear after a revision that it is not an ancestor
of.

> > I'm sure that John did not intend to say that git "sucks", and I
> > firmly believe that none of us believes that, and certainly no-one
> > would argue that it is not faster than bzr.
> >
> > I think there are still criticisms of the UI, even though it has
> > significantly improved recently.
> 
> Sigh.  So it is fine if the logs of bzr are really slow because the UI
> of git is considered not all too hot.
> 

Please don't put words in to my mouth.

I was trying to say that while we might acknowledge that git is faster,
there are still things we are trying to do with bzr that make it
worthwile working on it, rather than all switching to hack on git.

While we may be able to offer some UI improvements to git itself there
may be fundamental differences that mean git may always fall short of
what we would like. There are also things that bzr can do that git
will never do (barring any big changes in direction), for instance
foreign branch support.

Thanks,

James