Re: git-diff-tree rename detection for single file

On Tue, 18 Oct 2005, Junio C Hamano wrote:

Gaah. Why? It's really not possible to do it efficiently inside git-diff-xyz, so whatever implementation would basically boil down to something you can already do with some trivial scripting, basically boiling down to:

	git-diff-tree -r -M | grep pathnamelist | git-diff-helper

Now, several reasons why it's much better to do this kind of "--late-pathspec" at a higher level (instead of inside the git-diff-xyz family):

 (a) git-diff-xyz is already some of the more complex core parts. It's not 
     likely a good idea to make them any more complex, unless there's some 
     very fundamental reason for it.

 (b) without pathname limits, git-diff-tree is very slow. Well, it's 
     actually very fast compared to something braindead like CVS, but if 
     you want to track a single file over a thousand releases, it's MUCH 
     MUCH faster to do the pathname limit at the beginning. Otherwise 
     you'll spend all your time reading and comparing big trees with tens 
     of thousands of entries.

 (c) with a higher-level thing, what you can do is have a TWO-phase thing: 
     use the fast pathname limiter in git-diff-tree to figure out when 
     that file changes in history, and then _only_ for those commits do 
     you go back and then do the much more expensive "git-diff-tree -r -M" 
     followed by the pathname-limiting post-processing.

See what I'm saying? You really can do the post-processing outside of git-diff-tree, and you will in fact be much better off if you do so.

The performance impact of pruning the pathnames _before_ diffing them was absolutely staggering. You couldn't reasonably do a "git-whatchanged -p" on the kernel for a single file if you didn't do it the way we do it now.

			Linus