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