From: Paul Mackerras <paulus@samba.org>
Date: Tue, 10 May 2005 00:33:00 GMT
Subject: Re: Prototype git commit viewer
Message-ID: <17024.316.828536.230448@cargo.ozlabs.ibm.com>
In-Reply-To: <m3fywwjktf.fsf@defiant.localdomain>

Krzysztof Halasa writes:

> Nice. I wonder how well would it work with a longer history, say all
> linux-2.[56] data. It takes gitk ~ 10 seconds to read ~ 1000 Linux
> commits from cache now, on my system.

Any arguments you give to gitk (other than -b and -d) get passed to
git-rev-tree, so you can just look at a section of the tree.  (I just
fixed a bug where it would crash if a commit had a parent that wasn't
listed in the git-rev-tree output, so refetch if you want to try it.)
So you can do e.g.
	gitk 88d7bd8cb9eb8d64bf7997600b0d64f7834047c5 \
		^a2755a80f40e5794ddc20e00f781af9d6320fafb

to see all the commits from v2.6.12-rc4 back to but not including
v2.6.12-rc3 (unfortunately git-rev-tree seems not to cope with being
given tags rather than commit ids).

Ultimately I want to add ways to select the range of commits you want
to look at, e.g. by tags or by dates.

So as long as git-rev-tree remains fast as the history grows, gitk
should remain usable for looking at reasonable-sized chunks of the
history.  There are various things I can do to make gitk faster, too,
up to and including tcl bindings for the core git library. :)  

> In fact I'm thinking about something working with WWW browser. I've
> written a very simple experimental show-tree tool in C and it seems
> reading current Linux tree (no HTTP output yet) takes 0.065s with it.
> 
> Now I'm thinking about output language. (X)HTML seems to be not
> capable (I'm not HTML expert, please correct me if I'm wrong).
> 
> Any idea of what can I use?

I think I am even less of an HTML expert than you. :)

Regards,
Paul.