On Sat, Nov 08, 2008 at 07:00:10PM +0700, Nguyen Thai Ngoc Duy wrote: > > The downsides are: > > > > - your cache is potentially bigger, since you are caching the score of > > every pair you look at, instead of just "good" pairs (OTOH, you are > > not doing a per-commit cache, which helps reduce the size) > > It is huge if you accidentially add --find-copies-harder to your > command, considering that every new file will be compared against > every files in tree (about 25k). Hmm, yeah. I was thinking you might be able to do some kind of cut-off on the caching (i.e., don't bother storing anything that didn't come close). But you can't safely assume that because an entry isn't there, it isn't worth seeing (since it might also just not have been computed yet). You could still organize by commit, and then each commit is either fully computed or not. But then you still have a pathspec problem. One thing you could do is just compute the rename score between all pairs, even if a pathspec is given, limit it to values over "0.5" (or something low, but that eliminates the totally uninteresting cases), and then store that as the complete cache for that commit (or tree pair, if you want to support that). Then you would have the full information and could do an arbitrary pathspec limit on it. If you wanted to set the rename threshold below 0.5, then we would have to recompute without the cache (but in practice, that should be rare). The real downside is that you pay for the whole-tree detection when you have asked for a pathspec (but only the first time, after which you can always generate from cache). Just thinking out loud... -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
