Re: --find-copies-harder finds fewer copies/renames than -C does

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 5, 2011, 18:59 UTC
Message-ID: <7voc7vch35.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1jukub7.uehx43wxtij7M%lists@haller-berlin.de>

lists@haller-berlin.de (Stefan Haller) writes:

Show 11 quoted lines

> The reason for this seems to be the condition
> "num_create * num_src > rename_limit * rename_limit" in diffcore_rename;
> --find-copies-harder exeeds the limit, so it turns off inexact rename
> dectection *completely*, while -C stays well below the limit.
>
> I had expected --find-copies-harder to still do inexact rename detection
> among the changed files in the commit in this case, and turn it off only
> for the unmodified files; I'm not familiar enough with the code to tell
> whether that would be easy to implement though.
>
> Any thoughts?

Two. When you can spend unlimited amount of resources, it would feel more intuitive if -C -C lifted rename-limit altogether. On the other hand, in a project where the difference does matter (i.e. you have far too many candidate sources), it is likely that -C -C without rename limit would run out of memory and not produce any result, so automatic lifting of rename limit is unacceptable as the default.

Setting rename-limit to match the size of your environment (perhaps do this once in the config) would make this a non-issue, so coming up with an automated way to do so might be an interesting exercise.