Add rename tracking to blame

[Christoph Rüßler (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 gitoxidemain.

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.

[Christoph Rüßler (cruessler)]

Sebastian Thiel (@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. 😄

[Sebastian Thiel (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.

[Christoph Rüßler (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?

[Christoph Rüßler (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.)

[Sebastian Thiel (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.

[Christoph Rüßler (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.

[Christoph Rüßler (cruessler)]

For the record: unfortunately, it seems quite hard to come up with a good test case for the issue fixed in this commit: Get current file_path from unblamed hunk. (I found the issue running gix-scripts on all of gitoxide, as mentioned in this comment.) If you’ve got any ideas, let me know! :-)

[Sebastian Thiel (Byron)]

In order to reproduce something like that one would have to have a way of git filter'ing all commits and files that relate to the ones that gix blame would want to read when following the blame-trail. Usually I also run these through copy_royal to retain the same diffs while removing the content.

With that one could probably build yet another tool to turn this information into a shell script which, when executed, reproduces the exact, non-linear history that is needed to perform a blame on a certain file. This is a project on its own but it would be super-valuable for gix blame I think, allowing to unit-test real-world test-cases without pulling in huge amounts of data.

Something like it git-copy-royal <pathspec> and then it outputs a shell-script along with file blobs that will compress well when put into a Git repository. The idea is that the shell-script produces the history, and incorporates the blobs from files that are in some asset directory. These can be named such that they delta-compress together maybe.

[Sebastian Thiel (Byron)]

I am doing an incremental review now, and you are welcome to chime in and look at intermediate results.
I plan to keep force-pushing into my commit for a while.

[Sebastian Thiel (Byron)]

Alright, that should be it!

Please take a look at the refactor to see if that works for you, or maybe I missed something.
As a major change, I wired rewrites up to options so it can be configured, which seems more adequate for a plumbing crate. It's less about disabling rewrite tracking and more about adjusting its values and possibly enable copy tracking as well.

Edit: tomorrow night I'd merge this if I don't hear from you.

[Christoph Rüßler (cruessler)]

I had a look, and everything’s looking good! Adding rewrites as an option is a good idea, I think.

I hope to be able to finish the blame history extraction tool over the weekend. I would then try and add a test case for the fix in 7435ed5.

[Christoph Rüßler (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 gitoxidemain.

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.

[Christoph Rüßler (cruessler)]

Sebastian Thiel (@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. 😄

[Sebastian Thiel (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.

[Christoph Rüßler (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?

[Christoph Rüßler (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.)

[Sebastian Thiel (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.

[Christoph Rüßler (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.

[Christoph Rüßler (cruessler)]

For the record: unfortunately, it seems quite hard to come up with a good test case for the issue fixed in this commit: Get current file_path from unblamed hunk. (I found the issue running gix-scripts on all of gitoxide, as mentioned in this comment.) If you’ve got any ideas, let me know! :-)

[Sebastian Thiel (Byron)]

In order to reproduce something like that one would have to have a way of git filter'ing all commits and files that relate to the ones that gix blame would want to read when following the blame-trail. Usually I also run these through copy_royal to retain the same diffs while removing the content.

With that one could probably build yet another tool to turn this information into a shell script which, when executed, reproduces the exact, non-linear history that is needed to perform a blame on a certain file. This is a project on its own but it would be super-valuable for gix blame I think, allowing to unit-test real-world test-cases without pulling in huge amounts of data.

Something like it git-copy-royal <pathspec> and then it outputs a shell-script along with file blobs that will compress well when put into a Git repository. The idea is that the shell-script produces the history, and incorporates the blobs from files that are in some asset directory. These can be named such that they delta-compress together maybe.

[Sebastian Thiel (Byron)]

I am doing an incremental review now, and you are welcome to chime in and look at intermediate results.
I plan to keep force-pushing into my commit for a while.

[Sebastian Thiel (Byron)]

Alright, that should be it!

Please take a look at the refactor to see if that works for you, or maybe I missed something.
As a major change, I wired rewrites up to options so it can be configured, which seems more adequate for a plumbing crate. It's less about disabling rewrite tracking and more about adjusting its values and possibly enable copy tracking as well.

Edit: tomorrow night I'd merge this if I don't hear from you.

[Christoph Rüßler (cruessler)]

I had a look, and everything’s looking good! Adding rewrites as an option is a good idea, I think.

I hope to be able to finish the blame history extraction tool over the weekend. I would then try and add a test case for the fix in 7435ed5.

[Christoph Rüßler (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 gitoxidemain.

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.

[Christoph Rüßler (cruessler)]

Sebastian Thiel (@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. 😄

[Sebastian Thiel (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.

[Christoph Rüßler (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?

[Christoph Rüßler (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.)

[Sebastian Thiel (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.

[Christoph Rüßler (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.

[Christoph Rüßler (cruessler)]

For the record: unfortunately, it seems quite hard to come up with a good test case for the issue fixed in this commit: Get current file_path from unblamed hunk. (I found the issue running gix-scripts on all of gitoxide, as mentioned in this comment.) If you’ve got any ideas, let me know! :-)

[Sebastian Thiel (Byron)]

In order to reproduce something like that one would have to have a way of git filter'ing all commits and files that relate to the ones that gix blame would want to read when following the blame-trail. Usually I also run these through copy_royal to retain the same diffs while removing the content.

With that one could probably build yet another tool to turn this information into a shell script which, when executed, reproduces the exact, non-linear history that is needed to perform a blame on a certain file. This is a project on its own but it would be super-valuable for gix blame I think, allowing to unit-test real-world test-cases without pulling in huge amounts of data.

Something like it git-copy-royal <pathspec> and then it outputs a shell-script along with file blobs that will compress well when put into a Git repository. The idea is that the shell-script produces the history, and incorporates the blobs from files that are in some asset directory. These can be named such that they delta-compress together maybe.

[Sebastian Thiel (Byron)]

I am doing an incremental review now, and you are welcome to chime in and look at intermediate results.
I plan to keep force-pushing into my commit for a while.

[Sebastian Thiel (Byron)]

Alright, that should be it!

Please take a look at the refactor to see if that works for you, or maybe I missed something.
As a major change, I wired rewrites up to options so it can be configured, which seems more adequate for a plumbing crate. It's less about disabling rewrite tracking and more about adjusting its values and possibly enable copy tracking as well.

Edit: tomorrow night I'd merge this if I don't hear from you.

[Christoph Rüßler (cruessler)]

I had a look, and everything’s looking good! Adding rewrites as an option is a good idea, I think.

I hope to be able to finish the blame history extraction tool over the weekend. I would then try and add a test case for the fix in 7435ed5.

[Christoph Rüßler (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 gitoxidemain.

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.

[Christoph Rüßler (cruessler)]

Sebastian Thiel (@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. 😄

[Sebastian Thiel (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.

[Christoph Rüßler (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?

[Christoph Rüßler (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.)

[Sebastian Thiel (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.

[Christoph Rüßler (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.

[Christoph Rüßler (cruessler)]

For the record: unfortunately, it seems quite hard to come up with a good test case for the issue fixed in this commit: Get current file_path from unblamed hunk. (I found the issue running gix-scripts on all of gitoxide, as mentioned in this comment.) If you’ve got any ideas, let me know! :-)

[Sebastian Thiel (Byron)]

In order to reproduce something like that one would have to have a way of git filter'ing all commits and files that relate to the ones that gix blame would want to read when following the blame-trail. Usually I also run these through copy_royal to retain the same diffs while removing the content.

With that one could probably build yet another tool to turn this information into a shell script which, when executed, reproduces the exact, non-linear history that is needed to perform a blame on a certain file. This is a project on its own but it would be super-valuable for gix blame I think, allowing to unit-test real-world test-cases without pulling in huge amounts of data.

Something like it git-copy-royal <pathspec> and then it outputs a shell-script along with file blobs that will compress well when put into a Git repository. The idea is that the shell-script produces the history, and incorporates the blobs from files that are in some asset directory. These can be named such that they delta-compress together maybe.

[Sebastian Thiel (Byron)]

I am doing an incremental review now, and you are welcome to chime in and look at intermediate results.
I plan to keep force-pushing into my commit for a while.

[Sebastian Thiel (Byron)]

Alright, that should be it!

Please take a look at the refactor to see if that works for you, or maybe I missed something.
As a major change, I wired rewrites up to options so it can be configured, which seems more adequate for a plumbing crate. It's less about disabling rewrite tracking and more about adjusting its values and possibly enable copy tracking as well.

Edit: tomorrow night I'd merge this if I don't hear from you.

[Christoph Rüßler (cruessler)]

I had a look, and everything’s looking good! Adding rewrites as an option is a good idea, I think.

I hope to be able to finish the blame history extraction tool over the weekend. I would then try and add a test case for the fix in 7435ed5.

[Christoph Rüßler (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 gitoxidemain.

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.

[Christoph Rüßler (cruessler)]

Sebastian Thiel (@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. 😄

[Sebastian Thiel (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.

[Christoph Rüßler (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?

[Christoph Rüßler (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.)

[Sebastian Thiel (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.

[Christoph Rüßler (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.

[Christoph Rüßler (cruessler)]

For the record: unfortunately, it seems quite hard to come up with a good test case for the issue fixed in this commit: Get current file_path from unblamed hunk. (I found the issue running gix-scripts on all of gitoxide, as mentioned in this comment.) If you’ve got any ideas, let me know! :-)

[Sebastian Thiel (Byron)]

In order to reproduce something like that one would have to have a way of git filter'ing all commits and files that relate to the ones that gix blame would want to read when following the blame-trail. Usually I also run these through copy_royal to retain the same diffs while removing the content.

With that one could probably build yet another tool to turn this information into a shell script which, when executed, reproduces the exact, non-linear history that is needed to perform a blame on a certain file. This is a project on its own but it would be super-valuable for gix blame I think, allowing to unit-test real-world test-cases without pulling in huge amounts of data.

Something like it git-copy-royal <pathspec> and then it outputs a shell-script along with file blobs that will compress well when put into a Git repository. The idea is that the shell-script produces the history, and incorporates the blobs from files that are in some asset directory. These can be named such that they delta-compress together maybe.

[Sebastian Thiel (Byron)]

I am doing an incremental review now, and you are welcome to chime in and look at intermediate results.
I plan to keep force-pushing into my commit for a while.

[Sebastian Thiel (Byron)]

Alright, that should be it!

Please take a look at the refactor to see if that works for you, or maybe I missed something.
As a major change, I wired rewrites up to options so it can be configured, which seems more adequate for a plumbing crate. It's less about disabling rewrite tracking and more about adjusting its values and possibly enable copy tracking as well.

Edit: tomorrow night I'd merge this if I don't hear from you.

[Christoph Rüßler (cruessler)]

I had a look, and everything’s looking good! Adding rewrites as an option is a good idea, I think.

I hope to be able to finish the blame history extraction tool over the weekend. I would then try and add a test case for the fix in 7435ed5.

[Christoph Rüßler (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 gitoxidemain.

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.

[Christoph Rüßler (cruessler)]

Sebastian Thiel (@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. 😄

[Sebastian Thiel (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.

[Christoph Rüßler (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?

[Christoph Rüßler (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.)

[Sebastian Thiel (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.

[Christoph Rüßler (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.

[Christoph Rüßler (cruessler)]

For the record: unfortunately, it seems quite hard to come up with a good test case for the issue fixed in this commit: Get current file_path from unblamed hunk. (I found the issue running gix-scripts on all of gitoxide, as mentioned in this comment.) If you’ve got any ideas, let me know! :-)

[Sebastian Thiel (Byron)]

In order to reproduce something like that one would have to have a way of git filter'ing all commits and files that relate to the ones that gix blame would want to read when following the blame-trail. Usually I also run these through copy_royal to retain the same diffs while removing the content.

With that one could probably build yet another tool to turn this information into a shell script which, when executed, reproduces the exact, non-linear history that is needed to perform a blame on a certain file. This is a project on its own but it would be super-valuable for gix blame I think, allowing to unit-test real-world test-cases without pulling in huge amounts of data.

Something like it git-copy-royal <pathspec> and then it outputs a shell-script along with file blobs that will compress well when put into a Git repository. The idea is that the shell-script produces the history, and incorporates the blobs from files that are in some asset directory. These can be named such that they delta-compress together maybe.

[Sebastian Thiel (Byron)]

I am doing an incremental review now, and you are welcome to chime in and look at intermediate results.
I plan to keep force-pushing into my commit for a while.

[Sebastian Thiel (Byron)]

Alright, that should be it!

Please take a look at the refactor to see if that works for you, or maybe I missed something.
As a major change, I wired rewrites up to options so it can be configured, which seems more adequate for a plumbing crate. It's less about disabling rewrite tracking and more about adjusting its values and possibly enable copy tracking as well.

Edit: tomorrow night I'd merge this if I don't hear from you.

[Christoph Rüßler (cruessler)]

I had a look, and everything’s looking good! Adding rewrites as an option is a good idea, I think.

I hope to be able to finish the blame history extraction tool over the weekend. I would then try and add a test case for the fix in 7435ed5.

[Christoph Rüßler (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 gitoxidemain.

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.

[Christoph Rüßler (cruessler)]

Sebastian Thiel (@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. 😄

[Sebastian Thiel (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.

[Christoph Rüßler (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?

[Christoph Rüßler (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.)

[Sebastian Thiel (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.

[Christoph Rüßler (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.

[Christoph Rüßler (cruessler)]

For the record: unfortunately, it seems quite hard to come up with a good test case for the issue fixed in this commit: Get current file_path from unblamed hunk. (I found the issue running gix-scripts on all of gitoxide, as mentioned in this comment.) If you’ve got any ideas, let me know! :-)

[Sebastian Thiel (Byron)]

In order to reproduce something like that one would have to have a way of git filter'ing all commits and files that relate to the ones that gix blame would want to read when following the blame-trail. Usually I also run these through copy_royal to retain the same diffs while removing the content.

With that one could probably build yet another tool to turn this information into a shell script which, when executed, reproduces the exact, non-linear history that is needed to perform a blame on a certain file. This is a project on its own but it would be super-valuable for gix blame I think, allowing to unit-test real-world test-cases without pulling in huge amounts of data.

Something like it git-copy-royal <pathspec> and then it outputs a shell-script along with file blobs that will compress well when put into a Git repository. The idea is that the shell-script produces the history, and incorporates the blobs from files that are in some asset directory. These can be named such that they delta-compress together maybe.

[Sebastian Thiel (Byron)]

I am doing an incremental review now, and you are welcome to chime in and look at intermediate results.
I plan to keep force-pushing into my commit for a while.

[Sebastian Thiel (Byron)]

Alright, that should be it!

Please take a look at the refactor to see if that works for you, or maybe I missed something.
As a major change, I wired rewrites up to options so it can be configured, which seems more adequate for a plumbing crate. It's less about disabling rewrite tracking and more about adjusting its values and possibly enable copy tracking as well.

Edit: tomorrow night I'd merge this if I don't hear from you.

[Christoph Rüßler (cruessler)]

I had a look, and everything’s looking good! Adding rewrites as an option is a good idea, I think.

I hope to be able to finish the blame history extraction tool over the weekend. I would then try and add a test case for the fix in 7435ed5.

[Christoph Rüßler (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 gitoxidemain.

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.

[Christoph Rüßler (cruessler)]

Sebastian Thiel (@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. 😄

[Sebastian Thiel (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.

[Christoph Rüßler (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?

[Christoph Rüßler (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.)

[Sebastian Thiel (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.

[Christoph Rüßler (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.

[Christoph Rüßler (cruessler)]

For the record: unfortunately, it seems quite hard to come up with a good test case for the issue fixed in this commit: Get current file_path from unblamed hunk. (I found the issue running gix-scripts on all of gitoxide, as mentioned in this comment.) If you’ve got any ideas, let me know! :-)

[Sebastian Thiel (Byron)]

In order to reproduce something like that one would have to have a way of git filter'ing all commits and files that relate to the ones that gix blame would want to read when following the blame-trail. Usually I also run these through copy_royal to retain the same diffs while removing the content.

With that one could probably build yet another tool to turn this information into a shell script which, when executed, reproduces the exact, non-linear history that is needed to perform a blame on a certain file. This is a project on its own but it would be super-valuable for gix blame I think, allowing to unit-test real-world test-cases without pulling in huge amounts of data.

Something like it git-copy-royal <pathspec> and then it outputs a shell-script along with file blobs that will compress well when put into a Git repository. The idea is that the shell-script produces the history, and incorporates the blobs from files that are in some asset directory. These can be named such that they delta-compress together maybe.

[Sebastian Thiel (Byron)]

I am doing an incremental review now, and you are welcome to chime in and look at intermediate results.
I plan to keep force-pushing into my commit for a while.

[Sebastian Thiel (Byron)]

Alright, that should be it!

Please take a look at the refactor to see if that works for you, or maybe I missed something.
As a major change, I wired rewrites up to options so it can be configured, which seems more adequate for a plumbing crate. It's less about disabling rewrite tracking and more about adjusting its values and possibly enable copy tracking as well.

Edit: tomorrow night I'd merge this if I don't hear from you.

[Christoph Rüßler (cruessler)]

I had a look, and everything’s looking good! Adding rewrites as an option is a good idea, I think.

I hope to be able to finish the blame history extraction tool over the weekend. I would then try and add a test case for the fix in 7435ed5.