lists@xxxxxxxxxxxxxxxx (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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html