Re: Trac+Git: rev-list with pathspec performance?

[Stephen Bash <bash@genarts.com>]

> > Note that there is proof of concept
> > "tree blame" (in Perl) which generates such 'last change to file'
> > information, I think faster than running 'git rev-list -1 <file>'
> > for
> > each file. Even better would be to encode used algorithm in C.
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/150063/focus=150183
> 
> My early experiments with your script are good for speed, but for some
> reason I'm always getting the first commit for a file rather than the
> most recent. I'll do some experimenting to see if I can uncover the
> issue.

Following up, I had to add -r to the diff-tree command line when requesting a subdirectory to work around the problem (script always returned the first commit).

I'm curious if it's faster to get the SHA of the sub-tree and compare that before actually running diff-tree?  And for that matter, just run diff-tree on the sub-tree that we care about rather than a recursive sub-tree on the root?  These may be early optimizations, but they're ideas that occurred to me while debugging the code...

> > P.S. Alternate solution would be to simply get rid of SVN-inspired
> > view.  Git tracks history of a *project* as a whole, not set of
> > histories for individual files (like CVS).

After a lot of experimentation, this is basically what we did.  I modified the Trac templates to not list the last change SHA or log message in the directory view.  After all my testing, I just don't think there's a fast way to get this information from Git.  This blame-dir script is the fastest alternative I've tried (about 5x faster than rev-list'ing each file), but it's still ~30 seconds on my machine (which is faster than our web server), and IMHO that's too long to ask a user to wait for a page to load.

Thanks,
Stephen