Re: Can I have this, pretty please?

[Paul Mackerras <paulus@samba.org>]

Linus Torvalds writes:

> Well, gitk has certainly had performance problems in the past, they've 
> been fixable. I think this should just be fixed too. And if the rev-list 
> is fast enough, then the gitk fix may well be to just not compute the 
> *whole* history - ie the solution may be as simple as stopping the 
> background job that does all the graph calculations when it is (pick a 
> point at random) something like a thousand commits into the graph, and the 
> user hasn't scrolled down..

I have made a "dev" branch in the gitk.git repository that has some
tweaks to the graph layout algorithm which change the appearance a
bit; specifically it doesn't continue the graph lines downwards until
it has to terminate them with an arrow because the graph is getting
too wide.  Instead, it always terminates them if they are going to be
longer than a certain length (about 100 rows).  Also I made some
changes to reduce the incidence of two lines having a corner at the
same point, for visual clarity.

The point of terminating the graph lines early is that it means gitk
won't have to lay out the whole graph, just the visible bits and a
limited number of rows around that.  So I'm interested to know if
people think it looks OK visually.  (I think it's actually better,
myself.)

The other thing that takes time is reading in the topology for the
previous/next tag computations.  I did a patch that wrote out the
topology to a cache file but I ran into some problems where the cache
includes commits that have gone away since the cache was created.
What I need to do to update the cached information is basically the
equivalent of

	git rev-list --all ^root1 ^root2 ...

where root1, root2, etc. are the commits in the cache that had no
children (and of which all the other commits in the cache are
descendents).  However, git rev-list will barf if those commits no
longer exist.  Currently the only solution I can see is to validate
them one by one with separate invocations of git rev-list or something
(git rev-parse won't do).

Would it be possible to make git rev-list ignore commits that don't
exist if they have a "^" in front of them, i.e. where we're asking for
them to be excluded anyway?  If we can do that (or something
equivalent) then I can make the cache work reliably.  It does speed up
gitk enormously, and the cache file is only about 3MB for the kernel
tree, so it seems well worth while.

Paul.