git-viz tool for visualising commit trees

git-viz tool for visualising commit trees

[Petr Baudis]

  Hi,

  just FYI, Olivier Andrieu was kind enough to port his monotone-viz
tool to git (http://oandrieu.nerim.net/monotone-viz/ - use the one from
the monotone repository). The tool visualizes the history flow nicely;
see

	http://rover.dkm.cz/~pasky/gitviz1.png
	http://rover.dkm.cz/~pasky/gitviz2.png
	http://rover.dkm.cz/~pasky/gitviz3.png
	http://rover.dkm.cz/~pasky/gitviz4.png
	http://rover.dkm.cz/~pasky/gitviz5.png
	http://rover.dkm.cz/~pasky/gitviz6.png
	http://rover.dkm.cz/~pasky/gitviz7.png

for some screenshots.

  Kind regards,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: git-viz tool for visualising commit trees

[Ingo Molnar]

* Petr Baudis <pasky@ucw.cz> wrote:

>   Hi,
> 
>   just FYI, Olivier Andrieu was kind enough to port his monotone-viz 
> tool to git (http://oandrieu.nerim.net/monotone-viz/ - use the one 
> from the monotone repository). The tool visualizes the history flow 
> nicely; see
> 
> 	http://rover.dkm.cz/~pasky/gitviz1.png
> 	http://rover.dkm.cz/~pasky/gitviz2.png
> 	http://rover.dkm.cz/~pasky/gitviz3.png
> 	http://rover.dkm.cz/~pasky/gitviz4.png
> 	http://rover.dkm.cz/~pasky/gitviz5.png
> 	http://rover.dkm.cz/~pasky/gitviz6.png
> 	http://rover.dkm.cz/~pasky/gitviz7.png
> 
> for some screenshots.

really nice stuff! Any plans to include it in git-pasky, via 'git gui' 
option or so? Also, which particular version has this included - the 
freshest tarball on the monotone-viz download site doesnt seem to 
include it.

	Ingo

Re: git-viz tool for visualising commit trees

[Petr Baudis]

Dear diary, on Wed, Apr 20, 2005 at 12:08:24PM CEST, I got a letter
where Ingo Molnar <mingo@elte.hu> told me that...
> * Petr Baudis <pasky@ucw.cz> wrote:
> >   just FYI, Olivier Andrieu was kind enough to port his monotone-viz 
> > tool to git (http://oandrieu.nerim.net/monotone-viz/ - use the one 
> > from the monotone repository). The tool visualizes the history flow 
> > nicely; see
> > for some screenshots.
> 
> really nice stuff! Any plans to include it in git-pasky, via 'git gui' 
> option or so? Also, which particular version has this included - the 
> freshest tarball on the monotone-viz download site doesnt seem to 
> include it.

AFAIK you need Monotone and grab it from the monotone repository.

git gui sounds interesting, but perhaps in longer horizon, and perhaps
not as an integral part of git-pasky. I don't know ocaml and it's rather
large thing.

Point'n'drag merges, anyone? ;-))

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: git-viz tool for visualising commit trees

[Olivier Andrieu]

 > Ingo Molnar <mingo@elte.hu> [Wed, 20 Apr 2005]:
 > 
 > * Petr Baudis <pasky@ucw.cz> wrote:
 > 
 > >   Hi,
 > > 
 > >   just FYI, Olivier Andrieu was kind enough to port his monotone-viz 
 > > tool to git (http://oandrieu.nerim.net/monotone-viz/ - use the one 
 > > from the monotone repository). The tool visualizes the history flow 
 > > nicely; see
 > > 
 > > 	http://rover.dkm.cz/~pasky/gitviz1.png
 > > 	http://rover.dkm.cz/~pasky/gitviz2.png
 > > 	http://rover.dkm.cz/~pasky/gitviz3.png
 > > 	http://rover.dkm.cz/~pasky/gitviz4.png
 > > 	http://rover.dkm.cz/~pasky/gitviz5.png
 > > 	http://rover.dkm.cz/~pasky/gitviz6.png
 > > 	http://rover.dkm.cz/~pasky/gitviz7.png
 > > 
 > > for some screenshots.
 > 
 > really nice stuff! Any plans to include it in git-pasky, via 'git gui' 
 > option or so? Also, which particular version has this included - the 
 > freshest tarball on the monotone-viz download site doesnt seem to 
 > include it.

I'll post a tarball soon. You can also get it from the monotone
repository, but I wouldn't recommend it unless you want to try
monotone as well : that involves a rather large download.

-- 
   Olivier

Re: git-viz tool for visualising commit trees

[Olivier Andrieu]

 > Ingo Molnar <mingo@elte.hu> [Wed, 20 Apr 2005]:
 > 
 > * Petr Baudis <pasky@ucw.cz> wrote:
 > 
 > >   Hi,
 > > 
 > >   just FYI, Olivier Andrieu was kind enough to port his monotone-viz 
 > > tool to git (http://oandrieu.nerim.net/monotone-viz/ - use the one 
 > > from the monotone repository). The tool visualizes the history flow 
 > > nicely; see
 > > 
 > > 	http://rover.dkm.cz/~pasky/gitviz1.png
 > > 	http://rover.dkm.cz/~pasky/gitviz2.png
 > > 	http://rover.dkm.cz/~pasky/gitviz3.png
 > > 	http://rover.dkm.cz/~pasky/gitviz4.png
 > > 	http://rover.dkm.cz/~pasky/gitviz5.png
 > > 	http://rover.dkm.cz/~pasky/gitviz6.png
 > > 	http://rover.dkm.cz/~pasky/gitviz7.png
 > > 
 > > for some screenshots.
 > 
 > really nice stuff! Any plans to include it in git-pasky, via 'git gui' 
 > option or so? Also, which particular version has this included - the 
 > freshest tarball on the monotone-viz download site doesnt seem to 
 > include it.

There, here's a tarball :
  http://oandrieu.nerim.net/monotone-viz/git-viz-0.1.tar.gz

and a binary, compiled on Fedora Core 3 :
  http://oandrieu.nerim.net/monotone-viz/git-viz.exe
  http://oandrieu.nerim.net/monotone-viz/README.git-viz

Please, bear in mind that this is really a hack. Since monotone and
git has very similar concepts, I merely replaced the code that was
accessing monotone's database (sqlite) by some code using git
tools. But the UI still has references to monotone all over the place,
a couple of things won't work, etc.

-- 
   Olivier

Re: git-viz tool for visualising commit trees

[Ingo Molnar]

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

> There, here's a tarball :
>   http://oandrieu.nerim.net/monotone-viz/git-viz-0.1.tar.gz

i'm trying to build it under Fedora Core 4 (devel), and there are two 
problems:

 - the build scripts seem to assume that "." is in PATH (or that the 
   needed viz_style.ml/etc. scripts are in the PATH).

adding "." to the PATH worked around this issue, a number of files built 
fine, but then it hit the next problem:

 ocamlopt.opt  -I /usr/lib/ocaml/lablgtk2 -I glib -I crypto -pp  -c viz_style.ml
 sh: - : invalid option
 Usage:  sh [GNU long option] [option] ...
         sh [GNU long option] [option] script-file ...
 GNU long options:
 [...]
 Preprocessor error
 make: *** [viz_style.cmx] Error 2

i've straced the build, and the bug comes from ocamlopt.opt executing:

  sh -c "-c 'viz_style.ml'"

which confuses the shell.

i've got ocaml-3.08.3-1, lablgtk-2.4.0-2 installed.

	Ingo

Re: git-viz tool for visualising commit trees

[Remi Vanicat]

Ingo Molnar <mingo@elte.hu> writes:

> * Olivier Andrieu <oandrieu@nerim.net> wrote:
>
>> There, here's a tarball :
>>   http://oandrieu.nerim.net/monotone-viz/git-viz-0.1.tar.gz
>
> i'm trying to build it under Fedora Core 4 (devel), and there are two 
> problems:
>
>  - the build scripts seem to assume that "." is in PATH (or that the 
>    needed viz_style.ml/etc. scripts are in the PATH).
>
> adding "." to the PATH worked around this issue, a number of files built 
> fine, but then it hit the next problem:
>
>  ocamlopt.opt  -I /usr/lib/ocaml/lablgtk2 -I glib -I crypto -pp  -c  viz_style.ml

There should be the command name of the preprocessor after the -pp
option. ocamlopt assume that it should use a preprocessor whose name
is -c, and fail. The problem must be in the configure script or the
makefile. A kick hack may be to launch make with the option
CAMLP4O=camlp4o (well, as it work here, I'm not sure of the exact
problem). 

-- 
Rémi Vanicat

Re: git-viz tool for visualising commit trees

[Olivier Andrieu]

 > Ingo Molnar [Thu, 21 Apr 2005]:
 > 
 > * Olivier Andrieu <oandrieu@nerim.net> wrote:
 > 
 > > There, here's a tarball :
 > >   http://oandrieu.nerim.net/monotone-viz/git-viz-0.1.tar.gz
 > 
 > i'm trying to build it under Fedora Core 4 (devel), and there are two 
 > problems:
 > 
 >  - the build scripts seem to assume that "." is in PATH (or that the 
 >    needed viz_style.ml/etc. scripts are in the PATH).

I'm not sure what's wrong here. It works fine for me when I run make
in the source directory and I don't have "." in PATH.

 > adding "." to the PATH worked around this issue, a number of files built 
 > fine, but then it hit the next problem:
 > 
 >  ocamlopt.opt  -I /usr/lib/ocaml/lablgtk2 -I glib -I crypto -pp  -c viz_style.ml
 >  sh: - : invalid option
 >  Usage:  sh [GNU long option] [option] ...
 >          sh [GNU long option] [option] script-file ...
 >  GNU long options:
 >  [...]
 >  Preprocessor error
 >  make: *** [viz_style.cmx] Error 2

That's probably because the configure script didn't find
camlp4. Camlp4 is a preprocessor for ocaml, it's needed for compiling
this file (viz_style.ml). Camlp4 is built with the ocaml compilers but
some package it separately. Try to find and install some ocaml-camlp4
(or camlp4) package and then re-run configure.

The configure script should signal an error when it doesn't find
camlp4, I'll change that.

-- 
   Olivier

Re: git-viz tool for visualising commit trees

[Ingo Molnar]

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

>  >  Preprocessor error
>  >  make: *** [viz_style.cmx] Error 2
> 
> That's probably because the configure script didn't find camlp4. 
> Camlp4 is a preprocessor for ocaml, it's needed for compiling this 
> file (viz_style.ml). Camlp4 is built with the ocaml compilers but some 
> package it separately. Try to find and install some ocaml-camlp4 (or 
> camlp4) package and then re-run configure.

ah, ok. I installed camlp4-3.08.3-1, and this also solved the other 
build problem as well that looked like to be a PATH problem.

when i run git-viz in a git-controlled directory, it seems to start up 
fine, but i get an error message: "Could not execute dot". Closing that 
window gives me the ability to do an 'Open', but git-viz does not seem 
to recognize any of my GIT repositories as such. (perhaps there's some 
GIT version dependency? I've got Linus' latest & greatest installed.)
 
> The configure script should signal an error when it doesn't find 
> camlp4, I'll change that.

fyi, it also didnt check for ocaml and lablgtk.

	Ingo

Re: git-viz tool for visualising commit trees

[Vincent Hanquez]

On Thu, Apr 21, 2005 at 03:02:42PM +0200, Ingo Molnar wrote:
> when i run git-viz in a git-controlled directory, it seems to start up 
> fine, but i get an error message: "Could not execute dot". Closing that 
> window gives me the ability to do an 'Open', but git-viz does not seem 
> to recognize any of my GIT repositories as such. (perhaps there's some 
> GIT version dependency? I've got Linus' latest & greatest installed.)

Hey Ingo,

you probably don't have graphviz (dot is one of graphviz executable).
I have no idea if that is related to the later though.
-- 
Vincent Hanquez

Re: git-viz tool for visualising commit trees

[Olivier Andrieu]

 > Ingo Molnar [Thu, 21 Apr 2005]:
 > 
 > * Olivier Andrieu <oandrieu@nerim.net> wrote:
 > 
 > >  >  Preprocessor error
 > >  >  make: *** [viz_style.cmx] Error 2
 > > 
 > > That's probably because the configure script didn't find camlp4. 
 > > Camlp4 is a preprocessor for ocaml, it's needed for compiling this 
 > > file (viz_style.ml). Camlp4 is built with the ocaml compilers but some 
 > > package it separately. Try to find and install some ocaml-camlp4 (or 
 > > camlp4) package and then re-run configure.
 > 
 > ah, ok. I installed camlp4-3.08.3-1, and this also solved the other 
 > build problem as well that looked like to be a PATH problem.
 > 
 > when i run git-viz in a git-controlled directory, it seems to start up 
 > fine, but i get an error message: "Could not execute dot". Closing that 
 > window gives me the ability to do an 'Open', but git-viz does not seem 
 > to recognize any of my GIT repositories as such. (perhaps there's some 
 > GIT version dependency? I've got Linus' latest & greatest
 > installed.)

Yes, git-viz uses the `dot' program from the graphviz package (it's in
Fedora Extra too I believe).

 > > The configure script should signal an error when it doesn't find 
 > > camlp4, I'll change that.
 > 
 > fyi, it also didnt check for ocaml and lablgtk.

er, what's weird. Here's what I get :

,----
| $ tar zxf git-viz-0.1.tar.gz
| $ cd git-viz-0.1
| $ ./configure
| checking for ocamlc... ocamlc
| OCaml version is 3.08.2
| OCaml library path is /usr/lib/ocaml
| checking for ocamlopt... ocamlopt
`----

-- 
   Olivier

Re: git-viz tool for visualising commit trees

[Ingo Molnar]

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

> Yes, git-viz uses the `dot' program from the graphviz package (it's in 
> Fedora Extra too I believe).

ah - that resolved all issues and i'm now running git-viz without any 
problems.

I just checked how the kernel repository looks like with it, and i'm 
impressed! The GUI is top-notch, and the whole graph output and 
navigation is very mature visually. Kudos!

a couple of suggestions that are in the 'taste' category:

- isnt left-to-right layout the more natural thing instead of top-down 
  (as it aligns with the reading direction)? It's selectable in the 
  preferences, but you might want to make it default. OTOH, top-down
  creates a more compressed view of the graph.

- there doesnt seem to be any performance difference between non-colored 
  and colored rendering - so you might as well want to make 'color by 
  author' (or color by branch) the default coloring, instead of 
  uncolored?

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

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.

	Ingo

Re: git-viz tool for visualising commit trees

[Ingo Molnar]

another thing, when i 'zoom out' of the graph far away (so that the 
whole graph becomes visible on the screen), i'm getting lots of such 
error messages:

 *** attempt to put segment in horiz list twice
 *** attempt to put segment in horiz list twice
 *** attempt to put segment in horiz list twice
 *** attempt to put segment in horiz list twice
 *** attempt to put segment in horiz list twice

this doesnt seem to impact anything though.

	Ingo

Re: git-viz tool for visualising commit trees

[Ingo Molnar]

is the 'diff with ancestor' feature supposed to work at this early 
stage? (it just does nothing when i click on it. It correctly offers two 
ancestors for merge points, but does nothing there either.)

	Ingo

Re: git-viz tool for visualising commit trees

[Petr Baudis]

Dear diary, on Thu, Apr 21, 2005 at 04:47:16PM CEST, I got a letter
where Ingo Molnar <mingo@elte.hu> told me that...
> 
> is the 'diff with ancestor' feature supposed to work at this early 
> stage? (it just does nothing when i click on it. It correctly offers two 
> ancestors for merge points, but does nothing there either.)

Doesn't it require git diff?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: git-viz tool for visualising commit trees

[Olivier Andrieu]

 > Ingo Molnar [Thu, 21 Apr 2005]:
 > I just checked how the kernel repository looks like with it, and
 > i'm impressed! The GUI is top-notch, and the whole graph output and
 > navigation is very mature visually. Kudos!

Thanks !

 > - there doesnt seem to be any performance difference between non-colored 
 >   and colored rendering - so you might as well want to make 'color by 
 >   author' (or color by branch) the default coloring, instead of 
 >   uncolored?

It has to call `cat-file commit' for each commit id to get the author
... it's just that's a lot of forks.

 > - 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 ?

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

Also, there's a -noaa option that draws an non-antialiased canvas :
it's noticeably faster (and uglier too).


 > Ingo Molnar [Thu, 21 Apr 2005]:
 > another thing, when i 'zoom out' of the graph far away (so that the 
 > whole graph becomes visible on the screen), i'm getting lots of such 
 > error messages:
 > 
 >  *** attempt to put segment in horiz list twice

Yes, this message must come from one of the libraries (libart most
probably)


 > Ingo Molnar [Thu, 21 Apr 2005]:
 > is the 'diff with ancestor' feature supposed to work at this early
 > stage? (it just does nothing when i click on it. It correctly
 > offers two ancestors for merge points, but does nothing there
 > either.)

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

Thanks for the suggestions,
-- 
   Olivier

Re: git-viz tool for visualising commit trees

[Ingo Molnar]

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

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

>  > 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