On Sun, Oct 02, 2011 at 05:10:26PM +0200, Alexander Pepper wrote:
> Using 'git log --numstat --find-copies-harder dd4e90f9' yields "immutable.java" as you expected:
>
> $ git log --numstat --find-copies-harder dd4e90f9
> [...]
> 6 10 src/java/voldemort/annotations/concurrency/Immutable.java => contrib/ec2-testing/src/java/voldemort/utils/ClusterOperation.java
OK. That at least explains what's going on.
> So is there a way to tell --follow to only use --find-copies instead
> of --find-copies harder?
No, it's hard-coded.
> And what is the advantage of using "--find-copies-harder" over "--find-copies"?
It finds more copies. The rename detection works like this:
--find-renames: for each newly-created file, consider any deleted
files as possible sources
--find-copies: like above, but also consider any modified files as
possible sources
--find-copies-harder: like above, but consider any file in the
repository as a possible source
So in theory --find-copies-harder is the most accurate, but it is also
the most expensive. We can afford to do it for --follow since we're only
considering a small subset of the possible destinations.
So git is saying that your immutable.java is actually a better match;
it's just that we don't usually find it because it wasn't modified in
the same commit. Have you looked at the contents? Is it actually a
better match, or is git wrong?
-Peff
--
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