Linus Torvalds <[EMAIL PROTECTED]> writes: > This makes it somewhat more expensive - I was thinking about disabling it > in git-diff-tree, since the rename logic already knows how many > new/deleted files there are.
That's doable. I'll rig something up on my next GIT day, along with the clean-up for diff option handling which we have postponed for some time. Clearly this would introduce another option to diffcore. OTOH, you could take totally the opposite avenue and take advantage of the fact that git commit ancestry is immultable. Once commitdiff is made, you do not have to regenerate it but cache it and reuse for the next request. I may be mistaken, but I vaguely recall kernel.org webservers already does something like that. If you have infinite amount of disk space, you could choose to cache everything, and also prime the cache before any real users ask for a page. Once you go that route, you could even give -C flag for copy detection, with --find-copies-harder which is an ultra expensive option, and nobody would notice. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
