Re: New features in gitk

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Nov 2, 2007, 15:03 UTC
Message-ID: <alpine.LFD.0.999.0711020751290.3342@woody.linux-foundation.org>
In-Reply-To: <18218.63946.772767.179841@cargo.ozlabs.ibm.com>

On Fri, 2 Nov 2007, Paul Mackerras wrote:

> 
> How would that help?  That doesn't list about 2/3 of the commits at
> all.

Yeah, you'd have to do all the parent processing on your own, I guess that would be too slow.

Show 5 quoted lines

> In any case, no that's not the only reason.  The main reason is that
> it (i.e. --topo-order) spits out the commits in exactly the order that
> gitk wants to display them (of which the bit about parents coming
> after all their children is a part), and thus reduces the amount of
> processing I need to do in Tcl.

The thing is, you shouldn't *care* how long it takes to get 50,000+ commits.

You're only visualizing ~20 commits at a time. Ignore the rest.

THAT is the number that is timing-critical. You're optimizing for the wrong case - the "whole history" thing doesn't matter as much as the "recent history" does.

So I bet from a usability standpoint, you'd be *much* better off with something that might take ten times as long for the whole thing, if the first thirty lines show up in a third of the time.

In fact, if you want to really optimize parsing and that is a big issue, use

	git log --left-right --parents --pretty=format:"%m %H %P %an <%ae> %aD"

which will give you a single line per commit. I bet tk is good at reading single lines. Don't even read anythign else - until somebody actually *selects* the commit, at which point you do the diff *and* the full thing.

Yes, it will make things slower over-all. And no, the above won't work for the "search everywhere", which means that once people start searching for everything, you'll be screwed, but with somethign like the above, you'll get the first commits immediately and can start showing them.

And yes, if they come in the wrong order, you'll have to recalculate the display, but I thought you had something incremental already - ie you can always do it for just the current window of 100 commits or whatever.

			Linus