Prototype git commit viewer

Over the weekend I hacked up a prototype viewer for git commits in Tk. It's called gitk and is at:

	http://ozlabs.org/~paulus/gitk

(that's the actual script itself :).

It displays a window with two panes; the upper one shows a summary of all the commits with a graph on the left showing the relationship of the commits (each dot represents a commit, with lines joining parents and children). The list is displayed with the most recent commit at the top, and parents below their children.

If you click on a commit, the bottom pane shows more details of the commit including the commit comments.

I plan to add a pane to show the list of files changed by the commit, and provide a way to pop up a dirdiff-style diff viewer window to view the actual diffs. I also plan to add a way to view the diffs between arbitrary points in the graph using girdiff. There is quite a lot of UI tweaking to be done too. However, it's already quite useful in its current state.

Paul.

Good job --- I like it already. Especially the way it correctly handles oddballs like 211232bae64bcc60bbf5d1b5e5b2344c22ed767e ;-).

Dear diary, on Mon, May 09, 2005 at 03:40:13AM CEST, I got a letter where Paul Mackerras <paulus@samba.org> told me that...

What are its advantages to git-viz?

I haven't looked at git-viz in details, but from the screen-shot, I can say I prefer paulus one :)

But heh, since when should we limit ourselves to a single tool to do a given job ? :)

Petr Baudis writes:

As a kernel developer, when I do a pull from Linus' tree, the question I want to ask is "who has been making what changes?" That's why gitk shows the headline and author of each of 30 commits in one screenful. AFAICS from the screenshots, git-viz doesn't give me that density of information (and neither did bk revtool, for that matter).

It seems to me that git-viz makes the graph topology the primary thing and the details of the commits the secondary thing. I want it the other way around.

Paul.

Dear diary, on Tue, May 10, 2005 at 12:12:13AM CEST, I got a letter where Paul Mackerras <paulus@samba.org> told me that...

Yes, it looks indeed pretty nice, I have to say after actually looking at it.

Paul Mackerras <paulus@samba.org> 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.

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?

(will post the source if there is interest)

Krzysztof Halasa writes:

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. :)

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

Regards, Paul.

On Mon, May 09, 2005 at 11:40:13AM +1000, Paul Mackerras wrote:

Very nice, I like it a lot, thanks for doing this.

greg k-h