Subject: Re: suggestions for gitweb

From: Jakub Narebski <[email-masked]>
Date: Mon, 14 May 2007 18:49:35 +0200

On Mon, 14 May 2007, Petr Baudis <[email-masked]> 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