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

From: Jakub Narebski <jnareb@gmail.com>
Date: Sep 6, 2006, 21:18 UTC
Message-ID: <edndud$csb$1@sea.gmane.org>
In-Reply-To: <Pine.LNX.4.64.0609061404490.27779@g5.osdl.org>

Linus Torvalds wrote:

Show 7 quoted lines

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

Show 6 quoted lines

> 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