Add rename tracking to blame

[cruessler]

• Use pretty_assertion::assert_equal
• feat: follow renames in blame
• Adapt to changes in gix-blame

This PR adds rename tracking to gix-blame. Since the numbers below seem to be very promising, I’m going to mark this PR as ready!

There’s probably ways to make some of the code more efficient, but I think those would be micro-optimizations at this point. I compared this branch and main running gix blame CREDITS in the Linux kernel and if there is a difference, it is hard to distinguish from noise.

2025-05-14 Some numbers

I just ran some benchmarks on how the resulting blames compare to git. I ran the comparison on my copy of the gitoxide repository which, at the time of the benchmark, contained 2040 files in total tracked by git. HEAD was at 005e8fec0f1665afc42bda632f140d381eca9fe8 when I first ran the comparison. When I re-ran it on 2025-05-28, HEAD was at 5950c5886941ff3adf326985e2f0e6731e07f2a5.

main

Of 2040 files, 493 had identical blames while 1547 had blames with at least one line differing from git blame.

In the files that did not fully match git blame, 178,068/320,282 lines (55.60 %) matched git blame.

In all files, 229,618/371,832 lines (61.75 %) matched git blame.

Update 2025-05-28: In all files, 229,648/371,861 (61.76 %) matched git blame.

This branch

Of 2040 files, 1023 had identical blames while 1017 had blames with at least one line differing from git blame.

In the files that did not fully match git blame, 266,382/293,968 lines (90.62 %) matched git blame.

In all files, 343,595/371,181 lines (92.57 %) matched git blame.

Update 2025-05-28: Investigating the difference mentioned below, I found a bug in the initial implementation. After fixing it, about 600 more lines got attributed to the same commit git attributed them to. In all files, 344,215/371,861 (92.57 %) matched git blame.

This means that this PR attributes about 110,000 lines more to the same commits as git blame, compared to current gitoxide main.

I think I’m quite pleased with these numbers. 😄

There is a difference in total line numbers between both measurements that I’ll investigate, though I don’t think it changes the general picture. Update 2025-05-28: the difference pointed to a bug that I’ve fixed in a separate commit.

[cruessler]

@Byron I’ve found and fixed a bug in the initial implementation and marked the commit as ready for review again. I had initially found the bug running cargo run -- blame … on all files in the gitoxide repository. I didn’t come up with a good way to capture the conditions that triggered the bug in a test. I think this feature could now have reached a stage where I’m increasingly moving towards running cargo run -- blame … on whole repositories as some sort of extended test suite. I’m not entirely sure what follows from this, I just felt like I wanted to mention it. 😄

[Byron]

First of all, apologies for the late response. Maybe there should be a "later" tag to indicate I am delaying the review to when I think I have enough time.

I think I’m quite pleased with these numbers. 😄

These are very existing indeed! Do you think the code for producing them should live somewhere near gix-blame? It doesn't have to be great, it can be a dev-tool, no problem.

I’m not entirely sure what follows from this, I just felt like I wanted to mention it. 😄

I can only imagine how hard it must be to deduce the source of a bug or of inconsistencies with Git by merely comparing the outcome of gix blame and gix blame, that's true expert-mode. And I fully understand how hard it must be to even reproduce the conditions for such a difference, without operating on the same files (with the same history), it's basically prohibitively expensive if tests should be isolated. But what if these tests wouldn't be isolated? What if they use the parent repository, or else skip the test if there is none or if it's a shallow clone?
That way you'd be able to have a new class of tests which compare the outcome of Git and Gix programmatically.

Similar extensions I could imagine to add to gix blame (CLI), so there is a 'compare' mode that shows the differences between the same invocation in Git.

In any case, I hope to get to give the PR a first look soon.

[cruessler]

First of all, apologies for the late response. Maybe there should be a "later" tag to indicate I am delaying the review to when I think I have enough time.

No worries, that’s absolutely fine (though a tag would indeed be very helpful for planning)!

These are very existing indeed! Do you think the code for producing them should live somewhere near gix-blame? It doesn't have to be great, it can be a dev-tool, no problem.

Currently, the code can be found in a separate repository: https://github.com/cruessler/gix-scripts (plus a couple of local changes that I haven’t pushed yet). I’m very open to moving it somewhere in gix-blame, though, if it makes sense!

[…] What if they use the parent repository, or else skip the test if there is none or if it's a shallow clone? That way you'd be able to have a new class of tests which compare the outcome of Git and Gix programmatically.

That’s an interesting idea! Do you mean not using gix-testtools to create a repository, but using the local copy of gitoxide instead? Another somewhat similar idea I had was to run gix-scripts nightly, but I think it would be even better if some of these tests could be made part of the regular test suite.

Similar extensions I could imagine to add to gix blame (CLI), so there is a 'compare' mode that shows the differences between the same invocation in Git.

That also seems like a good idea! Is there anything similar in gitoxide yet? Do you imagine shelling out to git?

[cruessler]

I’ve pushed a couple of commits to https://github.com/cruessler/gix-scripts so that it now also counts matching and non-matching lines and the percentage of matching lines. (This is now the version I used to calculate the numbers in the description.)

[Byron]

No worries, that’s absolutely fine (though a tag would indeed be very helpful for planning)!

Since this is still quite rare, I think I will go with posting a message to indicate such plans. Let's also say that I want to finish the review this week(end) :)!

That’s an interesting idea! Do you mean not using gix-testtools to create a repository, but using the local copy of gitoxide instead?

Indeed, that's what I thought. Now, it's very dangerous to break isolation like that, but I'd think it can also be done well enough to avoid running in an unsuitable parent repository. Alternatively, we could find good ways to clone the whole repository on demand - in theory, a simple read-only sell script would do as part of the existing fixtures. That would be efficient as well except for on CI, and maybe there could even be a special case for that to reuse full clones of the parent repository if available. One can certainly get creative here.

Another somewhat similar idea I had was to run gix-scripts nightly, but I think it would be even better if some of these tests could be made part of the regular test suite.

This sounds more like stress-testing or continuous exploration of possible bugs, a bit like fuzzing. The system would have to be able to spend compute and collect data for later analysis. That also does sound like gix corpus could be used, but in a more automated fashion. Maybe that's a bit of a project on its own, also similar to cargo crater. I am pretty sure a rabbit lives in there as well, but a fun one!

That also seems like a good idea! Is there anything similar in gitoxide yet? Do you imagine shelling out to git?

Yes, exactly that. gix is a dev-tool and it can do that. Somewhere in the codebase I am already doing that as well.

[cruessler]

Since this is still quite rare, I think I will go with posting a message to indicate such plans. Let's also say that I want to finish the review this week(end) :)!

Works for me! :-)

One can certainly get creative here.

I’m going to try and can come up with something. :-)

Maybe that's a bit of a project on its own, also similar to cargo crater. I am pretty sure a rabbit lives in there as well, but a fun one!

Then I’m going to prepare for a chase and start experimenting in gix-scripts. In case this turns out to be useful, we can consider incorporating some of it in gitoxide itself.