hg log -G for bookmarks

[Matt Mackall]

On Fri, 2016-02-05 at 15:53 +0000, Uwe Brauer wrote:
> > > > "Simon" == Simon King <simon at simonking.org.uk> writes:
> 
>    > Which as far as I can tell is equivalent to the git version. There
>    > are 2 branches from a common ancestor. The "master" branch has a
>    > single commit with description "3", and the "book1" branch contains 2
>    > commits with descriptions "1" and "2".
> 
>    > Note that there are many ways to lay out the same graph, so the
>    > display isn't necessarily going to be identical, but the
>    > relationships between the nodes should always be the same.
> 
> I see, you are right, but  I find the hg graph easier to read. (My hope
> was that git and hg would chose the same lay out for the graph, but
> obviously they don't).

Mercurial has more information.

In particular, since every new commit gets appended to a compact changelog
index, the changelog itself is a proper partial ordering (all parents come
before their children) of the DAG. That ordering is also reflected in our
revision numbers. So when log -G draws a DAG, it has a natural stable order to
draw it in: the order each commit was added to the repo. It also means we can do
some DAG comparisons very quickly: commit 3000 obviously can't be an ancestor of
commit 2000.

Git has no such index of commits and thus no such ordering. In fact, every time
it wants to do a DAG operation, it must walk backward from a set of heads
through commit blobs and packs on disk to build up a partial graph structure in
memory. There's no ordering between different branches available aside from date
information. Is commit AAAA related to commit BBBB? Might have to unpack a huge
number of commit blobs to find out. And finding the children of AAAA is
potentially extremely expensive as well.

-- 
Mathematics is the supreme nostalgia of our time.