From: Jakub Narebski Date: Wed, 06 Sep 2006 17:06:04 GMT Subject: Re: [PATCH 0/7] gitweb: Trying to improve history view speed Message-ID: In-Reply-To: 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 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