Gitk commit order leads to unnecessarily long lines

Gitk commit order leads to unnecessarily long lines

[Sebastian Dörner]

Hi,
It seems like the order gitk uses for the commits sometimes leads to
overly long lines. My use case is this repository (note that this
svn-conversion is still WIP):
http://www.sebastian-doerner.de/kompare.tgz

Looking at this with "gitk --all" looks partly like this:
http://i.imgur.com/oewTq.png
Almost all the commits are in one branch. Rendering the merges at the
top much earlier would avoid this line chaos. Interestingly, if you
just render the relevant commits, it looks fine:
gitk 768493d381aceffc90f132b6accb1536af8a3cc3..0ef520d910208c4d53bdd915964107b5a98cdc08
The problem for the current algorithm is probably the single non-merge
commit before the merges.

Another instance in the same repo (again gitk --all) is this part:
http://i.imgur.com/0i2fF.png
Both the pink and right orange line merge from trunk into that kde4
branch. However, this is not obvious from the way it is drawn. I see
this problem is a bit "softly expressed", but I hope you see what I
mean. I think making the merge edges shorter would also make the
actual structure more obvious.

I have no good idea how to easily fix these problems, but I don't know
that much about how it works currently. I see it might involve some
more "intelligence" of the rendering algorithm (forward-looking of
some sort). So never mind if you don't have a fast fix. But I still
wanted to point out that the problem exists.

This might be related to this issue:
http://thread.gmane.org/gmane.comp.version-control.git/18097/focus=18103
git version 1.7.12

Thank you!

Regards

Sebastian