Linus Torvalds writes: > Paul, do this on the current git tree: > > gitk b0a3de42..dff86e28 > > and tell me it doesn't look horrid. Wow! That's spectacular! :) > Maybe it's not a new thing, and it's just that the recent pattern of > merges in the git tree makes any version of gitk do horrible things. A large part of it is that I took out the stuff where gitk used to reorder the commits it got from git-rev-list. One of the side-effects of doing the reordering was that for commits which aren't listed in the git-rev-list output (i.e. which are drawn with open circles), gitk was able to draw them immediately after their last child. Now gitk doesn't discover that they aren't listed until it has drawn all the commits that are listed, which means we can get a whole pile of open-circle commits at the bottom of the graph. I think the best thing to do is to change git-rev-list. One possibility would be to add an option to make git-rev-list omit parents that are not in the requested set, which would mean that gitk would not draw the open-circle commits any more. The other option would be to make git-rev-list list the open-circle commits explicitly, with an indication that they are not in the requested set but are parents of commits in the requested set. Or I can put the logic back into gitk. I'd rather do it in git-rev-list though since it will be faster that way. Do you think that having the open-circle commits in the graph is useful? Paul. - : 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