views:

490

answers:

2
A: 

When you take a closer look you will see that the both graphs are (almost) identical, but the presentation is different. That, which looks like 3 different branches, is actually one branch, but presented slightly different.

I wrote "almost" because revision numbers have been reordered. And this is really strange...

oo_olo_oo
The first picture belongs to the branched repository, and the second one to the original but with the changes of the branched repo merged back. Should not both images look the same?
azkotoki
It explains a lot. Number of revisions in different repositories don't have to be the same. Apparently main branch was merged as first, then the second branch was merged, and at the end - the tip of the repository. Version numbers are different, but there are still the same two branches.
oo_olo_oo
+4  A: 

The graph looks like this since the revisions are ordered by their revision numbers. The main repository has the revisions ordered and numbered like this:

0 Imported initial repo.
1 Trivial change to also echo b.
2 Added another echo for c.
3 Echo for d.
4 Echo for e.

This reflects the order in which the changesets were added to the repository. The feature branch repository has this order:

0 Imported initial repo.
1 Trivial change to also echo b.
3 Added another echo for c.
4 Automatic merge...
5 Echo for d.
6 Automatic merge...
7 Echo for e.
8 Automatic merge...

Again everything is ordered nicely. But when you pull the feature branch into the main repository only the missing changesets are added. The result in main is thus:

0 Imported initial repo.
1 Trivial change to also echo b.
2 Added another echo for c.
3 Echo for d.
4 Echo for e.
5 Refactored echos to print.
6 Automatic merge...
7 Automatic merge...
8 Automatic merge...

and the graph reflects this.

As you note, the repository is fine -- this is only an artifact of how the changesets are ordered on disk. If you want, you could swap the repository with the nice graph for the one with the ugly graph since they now contain the same changesets. Just remember to move any important settings from .hg/hgrc (copy the file from the clone with the ugly graph).

By the way, when I look at the graph in my clone of http://hg.intevation.org/mercurial/crew/ (the development branch for Mercurial) and compare it to the graph in a fresh clone of http://www.selenic.com/hg/ (the main branch for Mercurial) I see the same phenomenon.

Martin Geisler
Thanks for the answer Martin. BTW, I've noticed that when drawing the graph, revisions (and their respective parents) belonging to the second parent of a merge revision are considered to come from foreign branches. Is that correct? This means that when reintegrating branches, doing it by pushing or pulling will lead to different (graph) results.
azkotoki
That is true. I was also surpriced at first since I expected complete symmetry thare. But Mercurial keeps track of two parents for each changeset and they are actually ordered. When you make a normal non-merge commit the working copy parent becomes parent1 and parent2 is set to the null revision. You will therefore get different graphs depending on which heads your working copy reflects when doing a merge. A little surpricing, but not something that causes any problems in my experience.
Martin Geisler