Is there any way to change how graphs are drawn in TortoiseHg?

Question

Being used to how ClearCase draw graphs I find Mercurial's and TortoiseHg's way confusing at first glance.

This is how I'd like it to be represented: With static positions for branches. E.g. Maintenance branch to the left/right always and preferably in a straight line and not the current spaghetti curved branch it is now (see below link).

This is how it looks using the TortoiseHg Explorer. The graph is from a test repository. :-)

Is there any way to change how graphs are drawn in Mercurial?

[edit]

Check out MacHg and how it draws the graphs. This is more in line of what I'd like to see myself.

Answer 1

The problem is that any forking commit creates an "anonymous" branch (as opposed to a named branch, which is a slightly different concept), and the default graph view can't place commits in static columns without having good ids. Thus, the implementor gave up and we have the current graph.

Now, I think the first view you give is awesome, and it should be possible to use some heuristics to assign ids to anonymous branches depending on (developer1-a, developer2-a, developer2-b, etc). That'd be cool. :)

Contribution time!

Update

What I'd like to see:

• Commits sorted vertically by commit time, rather than revision integer id.
• Commits sorted horizontally, grouped by named branch, and per committer inside each branch. (And each committers commits should be near, in case a committer has forked and merged his own data.)

This means an algorithm has to look at all commits (that are to be viewed) before populating the view and placing the commit "dots" in the right column/row.

Three passes over all commits ought to suffice though, and each can be done in O(n) time, which is O(n) for everything:

• walk all to gather data (gather branches/committers) (O(n))
• sort branches/commits into suitable column order
• sort commits by commit time (O(n log n) or better O(n) with radix-sort on seconds since epoch)
• walk commits and draw dots and ancestor lines according to grouping

Maybe we need to be smart(er) when routing the lines between commits, but that remains to be seen. Especially, we could use vertical space between commit-dots to connect merges that are far apart vertically (i.e. in time), instead of using an entire column like the current algorithm