Re: [PATCH 8/8] gitweb: Remove --parents from call to git-rev-list in parse_rev_list

[Jakub Narebski <jnareb@gmail.com>]

Linus Torvalds wrote:

> On Wed, 6 Sep 2006, Jakub Narebski wrote:
>>
>> Benchmarks (7 means patch before, 8 means this patch):
> 
> Btw, you should possibly look at cold-cache numbers, and numbers for 
> projects that aren't fully packed. They can often be _dramatically_ 
> different.

By the way I forgot that the case 8 is for the repository with 1 commit
more, although that shouldn't matter much for paginated output. Still, it
is one commit more unpacked. Benchmark for 7 was also for partially packed
repository.
 
> That said, the dramatic change would probably be if there were some way to 
> avoid using "--full-history" (rather than "--parents", which doesn't add 
> _that_ much overhead), since that "follow all parents" behaviour of 
> full-history is usually what really makes a big deal.
> 
> But I guess for gitweb, you do want to use --full-history in this case ;(

It is now easy with patch 3/7 "Use @hist_opts as git-rev-list parameters in
git_history" to remove '--full-history' from git-rev-list parameters in
git_history subroutine. Or add '--remove-empty' which matters only for the
last page of file/directory history output.

I had some simple benchmark that shown that the earlier version with
filtering via piping git-rev-list to git-diff-tree --stdin -- <filename>
was slightly faster than git-rev-list --full-history -- <filename>
(current version). If I remember correctly of course. And this version can
be easily extended to include renames (but not file to directory changes).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git