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

On Wed, 6 Sep 2006, Jakub Narebski wrote:

Linus Torvalds wrote:

quoted

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.

Well, since you asked for full history, by definition it doesn't take 
place for merges, since you'll be wanting to follow both sides of the 
merge (to see the full history) regardless of whether the parents of that 
merge seem interesting or not.

Every single merge is for parents to be connected, or what?

Well, "--parents" on its own means that we want a connected graph. It's 
just that if you don't ask for full history, then the connected graph 
result is obviously much smaller.

Think "graphical visualizer", and you'll see what's going on. Do a

	gitk git.c
	gitk --full-history git.c

and see the difference, and you'll understand (gitk already asks for 
"--parents" on its own).

Basically, "--full-history" means that we traverse every parent of a 
merge, whether it looks interesting or not.

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.

Yes. Once you get rid of "--parents", git-rev-list should indeed do 
exactly what you want (because it no longer tries to keep things 
connected, and thus happily drops uninteresting merges).

Of course, there could well be a bug _there_, since "--full-history" isn't 
used very much (but "git whatchanged" uses it, so it should have gotten 
_some_ testing).

			Linus