Web lists-archives.com

Re: [Possible GIT Bug]

On Sun, Sep 09, 2018 at 12:04:58PM -0700, Bryan Turner wrote:

> Here, though, you've _explicitly limited_ Git to only the copied file.
> It's not allowed to consider any others, which means it can't "see"
> the source path anymore. As a result, the copy is detected as a
> straight add. Note that --find-copies-harder means the diff machinery
> is allowed to consider files that weren't modified in the commit as
> possible sources for copies, but that's still subject to your explicit
> filtering. In other words, if PATH_TO_SOURCE_FILE wasn't modified,
> running this would _not_ see a copy:
> git show -C 055f6c89fa4506037d1621761f13430f469b8029  --
> But running this would:
> git show -C -C 055f6c89fa4506037d1621761f13430f469b8029  --
> No bugs here. Everything is working as intended, if not, perhaps, as
> you expected.

Your explanation is correct. To be fair, though, it seems like
--find-copies-harder is made a lot less useful by the not considering
the larger set of sources, since that's kind of its point. I'm not sure
if this behavior actually is intentional, or simply what happens to
occur based on the combination of features.

You can do:

  git log -C C --full-diff $commit -- $path

to limit a traversal to commits touching $path, but still see the full
diff (including possible copy sources). But AFAIK there's no option to
limit the diff, but include extra copy sources.

I'd be tempted to say we should do that automatically when
--find-copies-harder is in effect, but it's possible that some people
actually do want the current behavior. For a single path it's silly, but
if you did something like this:

  git show -C -C $commit -- foo/

that would find differences in the foo/ directory, and find copies only
from sources in foo/. That limits the result, but also limits the
effort, which can be important given the cost of copy detection.