# --find-copies-harder finds fewer copies/renames than -C does 4 messages from 2011-01-05 to 2011-01-06. Participants: Stefan Haller, Junio C Hamano. Thread: https://gitlist.dev/t/26204 ## Stefan Haller, 2011-01-05 17:46 Subject: --find-copies-harder finds fewer copies/renames than -C does Message-ID: <1jukub7.uehx43wxtij7M%lists@haller-berlin.de> URL: https://gitlist.dev/e/1jukub7.uehx43wxtij7M%25lists%40haller-berlin.de ``` 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 " detects all 14 files as renames; "git show --find-copies-harder --name-status " 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? -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ ``` ## Junio C Hamano, 2011-01-05 18:59 Subject: Re: --find-copies-harder finds fewer copies/renames than -C does Message-ID: <7voc7vch35.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7voc7vch35.fsf%40alter.siamese.dyndns.org In-Reply-To: <1jukub7.uehx43wxtij7M%lists@haller-berlin.de> ``` lists@haller-berlin.de (Stefan Haller) writes: > 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. ``` ## Stefan Haller, 2011-01-06 16:54 Subject: Re: --find-copies-harder finds fewer copies/renames than -C does Message-ID: <1juopju.rh4v4z97i9hmM%lists@haller-berlin.de> URL: https://gitlist.dev/e/1juopju.rh4v4z97i9hmM%25lists%40haller-berlin.de In-Reply-To: <7voc7vch35.fsf@alter.siamese.dyndns.org> ``` Junio C Hamano wrote: > lists@haller-berlin.de (Stefan Haller) writes: > > > 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. 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? -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ ``` ## Junio C Hamano, 2011-01-06 20:42 Subject: Re: --find-copies-harder finds fewer copies/renames than -C does Message-ID: <7vhbdlahnp.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vhbdlahnp.fsf%40alter.siamese.dyndns.org In-Reply-To: <1juopju.rh4v4z97i9hmM%lists@haller-berlin.de> ``` lists@haller-berlin.de (Stefan Haller) writes: > 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? Maybe. Patches welcome ;-) ```