file history does not follow file renames
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
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
@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.
Even git_blame_file follows renames. We can look into that one :)
That fact significantly increases my hope that there is a simple way of following renames. :-)
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
actually it does exactly what I suspected internally:
rev walk starting with current filename:
- first a fast path-specced diff to see if we can sort this commit out early
- if it touches
current, do a full-diff to apply rename-detection - if it is in fact a rename change the
currentfilename 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)
@cruessler can you pick this up next? it should really be close to finish the PR
I’ll have a look!