gitui icon indicating copy to clipboard operation
gitui copied to clipboard

file history does not follow file renames

Open extrawurst opened this issue 2 years ago • 8 comments

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

Screenshot 2023-09-06 at 00 09 52

original implementation happened in #381 by @cruessler

extrawurst avatar Sep 05 '23 22:09 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

extrawurst avatar Sep 05 '23 22:09 extrawurst

@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.

cruessler avatar Sep 06 '23 07:09 cruessler

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

extrawurst avatar Sep 06 '23 07:09 extrawurst

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

cruessler avatar Sep 06 '23 07:09 cruessler

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 avatar Sep 06 '23 07:09 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 avatar Sep 06 '23 08:09 extrawurst

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

extrawurst avatar Mar 27 '24 11:03 extrawurst

I’ll have a look!

cruessler avatar Mar 27 '24 11:03 cruessler