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

From: Jeff King <peff@peff.net>
Date: Oct 2, 2011, 15:25 UTC
Message-ID: <20111002152517.GA10353@sigill.intra.peff.net>
In-Reply-To: <67B22035-4B90-4A68-8960-DDB58F640CD9@inf.fu-berlin.de>

On Sun, Oct 02, 2011 at 05:10:26PM +0200, Alexander Pepper wrote:

Show 5 quoted lines

> 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