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

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