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

quoted

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

quoted

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