Fix the rename detection limit checking
commit0024a54923a12f8c05ce4290f5ebefab0cce4336
authorLinus Torvalds <torvalds@linux-foundation.org>
Fri, 14 Sep 2007 17:39:48 +0000 (14 10:39 -0700)
committerJunio C Hamano <gitster@pobox.com>
Fri, 14 Sep 2007 19:12:57 +0000 (14 12:12 -0700)
tree751821e1d91ecd4c8579fe581d57ebd0d99b1e4e
parentb78281f7215c0236da6bd5c04ec5e500c83fd101
Fix the rename detection limit checking

This adds more proper rename detection limits. Instead of just checking
the limit against the number of potential rename destinations, we verify
that the rename matrix (which is what really matters) doesn't grow
ridiculously large, and we also make sure that we don't overflow when
doing the matrix size calculation.

This also changes the default limits from unlimited, to a rename matrix
that is limited to 100 entries on a side. You can raise it with the config
entry, or by using the "-l<n>" command line flag, but at least the default
is now a sane number that avoids spending lots of time (and memory) in
situations that likely don't merit it.

The choice of default value is of course very debatable. Limiting the
rename matrix to a 100x100 size will mean that even if you have just one
obvious rename, but you also create (or delete) 10,000 files, the rename
matrix will be so big that we disable the heuristics. Sounds reasonable to
me, but let's see if people hit this (and, perhaps more importantly,
actually *care*) in real life.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff.c
diffcore-rename.c
wt-status.c