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. :-)

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)

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

I’ll have a look!