file history does not follow file renames

[extrawurst]

I just renamed CHANGELOG.md to -> CHANGELOG-2.md and this is how the file history of it looks like:

original implementation happened in #381 by @cruessler

[extrawurst]

Unfortunately the rename detection happens on a diff level which means if we do the fast log walk with path spec filtering we won’t be able to detect renames. We need to actually benchmark this: maybe we just use the full revwalk and filter out diffs not touching the file in question or something more fancy like starting a new revwalk from the commit that does a rename which we can check if we find the added commit of the file

[cruessler]

@extrawurst Did you check what other tools, namely tig, do in this case? If they follow renames and are still reasonably fast, maybe we can get inspiration from their implementation.

[extrawurst]

Even git_blame_file follows renames. We can look into that one :)

[cruessler]

That fact significantly increases my hope that there is a simple way of following renames. :-)

[extrawurst]

it is confusing: https://github.com/libgit2/libgit2/blob/main/src/libgit2/blame_git.c#L431

it looks like they do what we do and limit the diff using path spec and still seem to be able to find renames in the diff. I gotta look into that

see below

[extrawurst]

actually it does exactly what I suspected internally:

rev walk starting with current filename:

1. first a fast path-specced diff to see if we can sort this commit out early
2. if it touches current, do a full-diff to apply rename-detection
3. if it is in fact a rename change the current filename and proceed with the revlog

interestingly they do not apply the optimisation that I had in mind: the status of the modification of the file in step 1. can be used to skip 2. if the status is not a file-add because a rename effectively looks like the initial commit of a file (with the new name)

[extrawurst]

@cruessler can you pick this up next? it should really be close to finish the PR

[cruessler]

I’ll have a look!