On Mon, 14 May 2007, Petr Baudis <pasky@xxxxxxx> wrote: > On Mon, May 14, 2007 at 10:53:15AM CEST, Michael Niedermayer wrote: >> also file size and last modified dates would be interresting on the tree >> page >> viewvc displays on its equivalent page, time since last change >> svn revission of the last change, the author/commiter of the last change >> and the corresponding abbreviated log entry > > I guess this is much easier to retrieve in svn than in git - you > actually have to walk all the history to figure out this information as > there's no global per-file info; so this is very troublesome > performance-wise. I think there were some patches on the mailinglist > that dit this, though I'm not sure. Might be reasonable to cache this > (and git history properties make it possible to nicely make a very > easily reusable cache for this information). I have sent some implementations of tree_blame, without any core support, directly in Perl (in gitweb), just like early versions of git-annotate. It did suck performance-wise quite a bit. You can find it in 'gitweb/tree_blame' branch in my git repository at repo.or.cz http://repo.or.cz/w/git/jnareb-git.git?a=shortlog;h=gitweb/tree_blame I think it would be nice to have --blame option to git-ls-tree (optionally copuled with --porcelain and perhaps --incremental, like in git-blame), which would return blame information for tree entries. It means that for each tree entry return commit closest to given commit (or furthest from a given commit) which has changed entry to current version. It should be much easier and faster than to do "blob"-blame. The --porcelain would also return 'last changed' info, like committer info for a commit-which-changed. But is this info actually interesting, or is it there in ViewVC because it is easy to get this info in CVS and Subversion? The "last changed" info for tree entries encourages to think of a history as a collection of per file histories... while git is all about whole project history. Note that history of two files is *more* than concatenation of histories of those individual files. See entries on GitFaq wiki page: > About file sizes, that also has some extra performance hit, but in > this case I suspect that it would be totally negligible (if implemented > at the plumbing level) - and I admit that I would like to see file sizes > too, they can help orientation in a foreign source tree a lot. It should be very easy to add --long / --sizes option to git-ls-tree which would return file sizes, perhaps after mode info. -- Jakub Narebski ShadeHawk on #git Poland - 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
