[PATCH] Fix tweak in similarity estimator.

[Junio C Hamano <junkio@cox.net>]

>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:

JCH> Plain -C (or -M) not working was a bug I now understand why,
JCH> and I would not be surprised that -C10 may give ridiculous
JCH> or hilarious results (false hits), but I am having trouble
JCH> reproducing the -C90 case.  Will do some more digging later.

An embarrasing math thinko was causing this confusion.

------------
Fix tweak in similarity estimator.

There was a screwy math bug in the estimator that confused what
-C1 meant and what -C9 meant, only in one of the early "cheap"
check, which resulted in quite confusing behaviour.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

diffcore-rename.c |    4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/diffcore-rename.c b/diffcore-rename.c
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -77,12 +77,12 @@ static int estimate_similarity(struct di
 
 	/* We would not consider edits that change the file size so
 	 * drastically.  delta_size must be smaller than
-	 * minimum_score/MAX_SCORE * min(src->size, dst->size).
+	 * (MAX_SCORE-minimum_score)/MAX_SCORE * min(src->size, dst->size).
 	 * Note that base_size == 0 case is handled here already
 	 * and the final score computation below would not have a
 	 * divide-by-zero issue.
 	 */
-	if (base_size * minimum_score < delta_size * MAX_SCORE)
+	if (base_size * (MAX_SCORE-minimum_score) < delta_size * MAX_SCORE)
 		return 0;
 
 	delta = diff_delta(src->data, src->size,