No subject

  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.