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
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