On Thu, 13 Sep 2007, Linus Torvalds wrote: > > Ok, I'm downloading those tar-balls to reproduce and hopefully see what's > going on, but I'm not going to be able to get at it today. Ok, I'm seeing it, and there are serious problems in the diffcore-rename code. The problems include things like actual overflow in 31 bits (a signed integer) from the multiplication of "num_create * num_src". But you'll almost certainly never even get there, because you'd long since have given up on the O(n^2) behaviour of the "cheap tests", that aren't really cheap enough, if only because even just comparing the 20-byte SHA1 hashes will basically take forever since they will always miss in the cache for lots of names. So yes, we really *have* to have a rename limit, even if it's only to avoid the technical bug of overflowing the multiplication. Testing this actually showed another bug too: "git diff" would actually never call "diff_setup_done() at all, if "diffopt.output_format" had been set explicitly to something. So doing a "git diff --stat" would totally ignore all the sanity checks (and, what caused me to find it, the initialization of "diffopt.rename_limit") that diff_setup_done() is supposed to do! So I'm going to send out two patches - one to fix the "diff_setup_done()" bug, and one that replaces the default rename_limit with something saner. Both seem to be real bugs. 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
