Re: diff.renames not working?

[Robert Dailey <rcdailey.lists@gmail.com>]

On Fri, Sep 13, 2019 at 10:30 PM Jeff King <peff@peff.net> wrote:
> SNIP
>
> > Now this looks more like it. I can actually see a useful diff here,
> > instead of everything looking like a new file. But there is a lot of
> > confusion here:
> >
> > 1. `diff --follow` is not a documented[1] option. Why does it work?
>
> Accident. :) See above.
>
> > 2. `diff -M` doesn't actually work either. It should, though. In fact,
> > I expected it to work as `--follow` does. But it doesn't.
>
> It doesn't work because this is a copy, not a rename.
>
> > 3. The `diff.renames` config doesn't seem to be working here, when it should.
>
> It does, but the pathspec prevents it from finding a source candidate.

Jeff, thanks so much. All of your examples help to contrast the
different behavior. I thought -M did copies & renames, that was my
misunderstanding. But the fact that you explained that the file spec
would prevent it from working as I'd like anyway means it doesn't
matter too much.

Ultimately my goal is to use the pathspec to filter what is visible, I
don't necessarily intend it to obscure my results due to internal
behavior. I realize there are performance obligations too (as you
described) but I feel like something like this should be
straightforward for end users. I consider myself a step above most
people with my understanding of Git and how it functions, and even I
was confused by this. Especially when it comes to folks I work with at
my day job, I just don't see them making sense of this.

To me, as transparently as possible, moves and copies should be
handled intrinsically. I realize there are technical challenges
(performance, ambiguities, etc), but anything that can be done to help
with that would go a long way with most users. Maybe a 3rd option from
your list to solve this issue might be adding some metadata to commits
or blob object types to record the pathspec of the file it was a copy
or move of. Even if this required you to first do a git cp/mv before
modifying the content, or a strict similarity threshold, I think it
would go a long way. That means that `diff` can utilize the metadata
in the object itself to find the path specs to follow, instead of
requiring some complex deduction logic that has a steep performance
cost.