Re: Gitk strangeness..

[Paul Mackerras <paulus@samba.org>]

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.