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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
