Junio C Hamano <gitster@xxxxxxxxx> wrote: > lists@xxxxxxxxxxxxxxxx (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/ -- 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