Thread (5 messages) flat view 5 messages, 1 author, 2016-06-15

Re: [PATCH 1/2] git-commit: Disallow unchanged tree in non-merge mode

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:34

Possibly related (same subject, not in this thread)


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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help