Re: Bug: impure renames may be reported as pure renames

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 21, 2024, 21:00 UTC
Message-ID: <xmqqzfvtmt1b.fsf@gitster.g>
In-Reply-To: <xmqqttm1pwsv.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> Alternatively, we could cap p->score to (MAX_SCORE-1) when
> similarity is _computed_ for filepair between non-identical blobs.
> That should happen in diffcore-rename.c:estimate_similarity().
> It would allow us to still _show_ "1 line changed among 1000 lines"
> case as R100 and still reject inexact renames via "-M100" from the
> command line, I think, as the "exact renames only" short-cut works
> with the finer-grained "score" values and not the coarser "percent"
> values, which might give us a better approach.

... the above may be "better" under a specific assumption: in the future, we would correct the rounding of scaling from 0..MAX_SCORE (or 0..MAX_SCORE-1) to 0..100 from the current "always round down" to "below 0.5 is rounded down, 0.5 and above is rounded up". If that happens, we would still honor the "Give -M100 to limit the rename detection to exact ones", and will exclude a change that modifies a single line in 1000, but if you say -M99, we would show such a change and it would be labelled as R100 as correctly rounded.