Re: Emacs Bazaar repository

[Stephen J. Turnbull]

James Westby writes:

 > 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.

Excuse me?  There may be something sensible you wish to say, but what
I have quoted is not it.  If A and B are not ordered by ancestry both
"AB" and "BA" fail to be a "merge sort" according to that criterion.

>From the blog:

  Always having merge commits means that "bzr log --short" and "bzr
  log --line" can give you a good summary of what happened on your
  branch, the commits you did, and the things that you merged.  It
  preserves a mainline for you in the left hand ancestry,

git-show-branch does this satisfactorily for me, although admittedly
more recent unmerged commits on other branches may show up first.
This is a *good* thing if I'm thinking about merging them, though.
OTOH, gitk simply prunes any unmerged commits by default.  How does
"merge sort" differ from "topological sort pruning unmerged commits"?
AFAICT in that case "not an ancestor" == "is a descendant" so topo
sort and merge sort are the same.  What am I missing?

  The indentation of the merged commits (and the fact they disappear
  with "--short" and "--line") means that mentally they become of
  lesser importance.

But that's exactly what I rarely want.  I know what I did, unless it
was a long time ago.  What I generally want to know is what others are
doing, and how that impacts my branch when I merge their code.

 > 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.

What is "foreign branch support", and why do you think that a program
which is amounts to being a browser for the universal revision graph
can't do it?  An URL would do.