Re: [PATCH 0/7] gitweb: Trying to improve history view speed
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Sep 6, 2006, 17:06 UTC
- Message-ID
- <edmv57$lt7$1@sea.gmane.org>
- In-Reply-To
- <Pine.LNX.4.64.0609060847521.27779@g5.osdl.org>
Linus Torvalds wrote:
Show 6 quoted lines
> 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