> > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html