Re: git-viz tool for visualising commit trees

From: Ingo Molnar <mingo@elte.hu>
Date: Apr 21, 2005, 22:06 UTC
Message-ID: <20050421220618.GA31657@elte.hu>
In-Reply-To: <20050421.221441.85407120.oandrieu@nerim.net>

* Olivier Andrieu <oandrieu@nerim.net> wrote:

Show 6 quoted lines

>  > - naming the boxes by key is quite meaningless. It would be more 
>  >   informative to see the author's email shortcuts in the boxes. Also, it 
>  >   would be nice to see some simple graphical feedback about the size and 
>  >   scope of a changeset, without having to zoom on it.
> 
> That's interesting. What do you mean exactly by scope ?

usually there are two interesting things about a patchset: how many lines does it change, and how many files. Patches that change lots of files (but change only a couple of lines in every file) have a 'large' scope. Patches that change 1-2 files have a 'small' scope. A pure 'number of lines changed' metric is useful too. Generally patches that have either a large linecount or a large scope are more interesting.

(I'm not sure how this could be displayed - perhaps the size of the rectangle could vary to a certain degree? Perhaps the shape too? Something non-numeric, so that one gets immediate visual feedback.)

Show 16 quoted lines

>  > i guess you know it, and i'm definitely not complaining about prototype 
>  > code, but rendering is quite slow: drawing the 340 changesets in the 
>  > current kernel repository takes 15 seconds on a 2 GHz P4. Drawing the 
>  > full kernel history (63,000 changesets) would take more than 45 minutes 
>  > on this box.
>  > 
>  > the current rate of kernel development is ~2000 changesets per month, so 
>  > drawing the kernel history will get 3 seconds slower every day - it will 
>  > exceed 1 minute in 20 days, so this will become a pressing issue quite 
>  > soon i suspect.
> 
> Right, it is slow. From what I could understand with a bit of 
> profiling, the problem is with the "text" canvas item for the boxes' 
> labels. I guess libgnomecanvas isn't using Pango properly or 
> something: it lookups the font with fontconfig each time I create such 
> an item. I'm not sure what I can do about this.

when the redrawing happens in the visible area then one can see how really slow it is: 100-200 msec per rectangle (!).

> It works with Petr Baudis' git-pasky (it calls `git diff'). I don't 
> know how to do that with the canonical git.

ah, ok. I guess it will start working once Petr's changes are merged into Linus' tree.

	Ingo