Re: [PATCH 0/7] gitweb: Trying to improve history view speed

[Jakub Narebski <jnareb@gmail.com>]

Linus Torvalds wrote:

> So the rule is:
> 
>  - using "--full-history" + "--parents" means that you want (surprise 
>    surprise) full history with parenthood, which means that you get all 
>    the connecting merges too. And since you asked for the _full_ history, 
>    that means EVERY SINGLE MERGE.

I just don't quite understand where <pathspec> filtering takes place 
in this case.

Every single merge is for parents to be connected, or what?
 
> So what you are asking for is pretty nonsensical. You ask for parenthood 
> info, but then you seem to not want to actually connect the dots. So why 
> do you ask for parents in the first place? If you don't want to connect 
> the commits to their parents, you shouldn't ask for it.

When I though about it, git_history needs not parents of a commit; from
parsed commit it needs only date, author and title/summary (and of course
commit sha1), so we can skip '--parents' option to git-rev-list, and have
nice _history of a file_, using only one call to git-rev-list to make it.

This means that parse_rev_list has to be changes, and that '--parents'
option must be specified explicitely as argument to parse_rev_list.

Besides [primitive] benchmarking shows that there we gain only a little:
1.53s user+sys vs 2.13s user+sys when run from command line, 
2.8s mean vs 3.6s mean when tested using ApacheBench...
that is _after_ paginating history output.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git