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

I was surprised to find out that --find-copies-harder can, under certain circumstances, detect fewer renames than -C does for a given commit. After some digging I think I understand now why this is so, but I find it extremely unintuitive, and would like to know what other people think about it. I had expected --find-copies-harder to always detect at least as many copies/renames as -C, and possibly more, but never less.

The case I had is this: I have a repo with about 10.000 files, and a commit with 14 files being moved to a different folder; half of them where unmodified moves, the other half had one-line modifications (similarity index 97% or so).

"git show -C --name-status <commit>" detects all 14 files as renames; "git show --find-copies-harder --name-status <commit>" only shows the unmodified moves as renames, the ones with modifications are shown as delete plus add.

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?

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

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.

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

But what about the suggestion of falling back to -C if --find-copies-harder exceeds the rename limit, but -C does not? Wouldn't that be the desired behaviour?

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

Maybe.  Patches welcome ;-)