Re: [idea] File history tracking hints

[Jeff King <peff@peff.net>]

On Mon, Sep 11, 2017 at 10:11:31AM +0300, Pavel Kretov wrote:

> Unfortunately, the heuristic can only deal with simple file renames with
> no substantial content changes; it's helpless when you:
> 
>  - rename file and change it's content significantly;
>  - split single file into several files;
>  - merge several files into another;
>  - copy entire file from another commit, and do other things like these.
> 
> However, if we're able to preserve this information, it's possible
> not only to do more accurate 'git blame', but also merge revisions with
> fewer conflicts.

This is definitely something that's been discussed before on the list
(though I'm not sure of the best keywords to dig for; Stefan found one
thread but I know there have been others).

And I don't think it's a totally unreasonable idea, but there are some
complications. The biggest one is that renames are really part of a
_diff_ between two endpoints. We think of them as attached to a commit
because we tend to talk about commits as a diff from state A to state B.

So obviously in the diff HEAD^ versus HEAD, we can look at the hints for
HEAD. But what about "git diff v1.0 v1.1", that may cover multiple
commits? Right now Git doesn't look at the intermediate commits at all.
And in fact we may not even know what they are, if the command is fed
two trees. Or the two endpoints may not have a sensible history (e.g.,
consider diffing between two branches, one of which has been rebased).

But even if we had a sensible set of commits to pull hints from (e.g.,
if v1.0 and v1.1 were in a linear relationship), it's not clear to me
how you would want to apply them to an end-to-end diff.

So I don't think that these kind of tracking hints make sense for a lot
of diffs (including merges, which use diffs between the endpoints and
the merge base).

Which isn't to say that they're useless. I agree that something like
"--follow" could benefit from an annotation that tells us when and how
to pick up the next step in the traversal. But of course somebody has to
make those annotations. If we had a tool to do it automatically, then we
could apply the same tool at run-time later.

But maybe if it were an optional annotation, people would want to use it
when the normal rename logic doesn't kick in. So perhaps a baby step in
this direction would be to teach something like "--follow" to "jump"
across a non-rename when it sees a special marking in the commit
message.

-Peff