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? -- 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