Re: Bug?: 'git log --find-copies' doesn't match 'git log --follow <rev> -- path/to/file'

[Jeff King <peff@peff.net>]

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