On Fri, 14 Sep 2007, Jeff King wrote: > On Thu, Sep 13, 2007 at 09:50:53PM -0700, Linus Torvalds wrote: > > > Oh, well. I'll look at it more closely tomorrow, but in the meantime, > > maybe you could try just this trivial test-patch (not meant as any kind of > > serious patch! Just making the default limit for rename detection go from > > "unlimited" to "don't bother if there's more than a hundred potential > > rename pairs"). > > Hrm, I didn't know about that option. My performance issue was > definitely rename detection; "git-show --raw" on the evil commit drops > from minutes to .039s with "-l100". Yeah, we should probably: - default to something larger but still reasonably sane (ie not 100, but perhaps 1000) - special-case the "identical rename", and have a higher limit for that (we already handle the identicals as a separate pass before we even start doing the similarity analysis - and it's the similarity analysis that can be the really expensive part) There's really no point in trying to do rename analysis for tons and tons of files - even if we find perfect renames, the diff is going to be unreadable by a human, so realistically nobody is ever going to care! A machine won't care whether it was done as a create/delete or a rename, and a human won't be bothered to read about thousands of renames, so we're just wasting time trying to make it prettier. So quite arguably, the only case we really care about for renames is when the numbers are small enough to be human-readable. Linus - 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
