Skip to content

Add a test combining renames and edits on multiple branches#2366

Merged
Sebastian Thiel (Byron) merged 3 commits intoGitoxideLabs:mainfrom
cruessler:add-another-test-for-rename-tracking
Jan 12, 2026
Merged

Add a test combining renames and edits on multiple branches#2366
Sebastian Thiel (Byron) merged 3 commits intoGitoxideLabs:mainfrom
cruessler:add-another-test-for-rename-tracking

Conversation

@cruessler
Copy link
Copy Markdown
Contributor

This PR is related to #2343 and #2308. I’m currently trying to find edge cases where gix blame and git blame diverge. This PR is the result of such a search. This specific test unfortunately does not fully capture the real-world case that initially triggered the search. All I know is that I was looking for some combination of a file that gets changed in one branch, gets changed and renamed in a different branch and then goes through a merge commit. This PR’s test case apparently is still missing at least one detail because it passes on main. I think it’s still useful as a test case as it captures a slightly different scenario than the already existing test case.

Details

The edge case I was investigating was the history of gix-pack/tests/Cargo.toml leading up to c9275b9.

@cruessler
Copy link
Copy Markdown
Contributor Author

Christoph Rüßler (cruessler) commented Jan 10, 2026

Sebastian Thiel (@Byron) I’m confused. I intentionally committed the archive at gix-blame/tests/fixtures/generated-archives/make_blame_rename_tracking_repo.tar, thinking this was the correct thing to do. Now CI wants me to recommit this fixture, but when I delete it and re-run the test that generated it in the first place, it does not get created. What’s the right way to fix this?

@EliahKagan
Copy link
Copy Markdown
Member

Eliah Kagan (EliahKagan) commented Jan 10, 2026

I'm not sure what the minimal amount of cleaning is, for gix-testtools to produce a .tar archive again, nor exactly what procedure you followed. I usually run gix clean -xde folllowed by cargo nextest run --workspace --no-fail-fast, since this also allows me to verify that exactly the archives I expect to be regenerated are what get regenerated, and that all tests pass (or that all tests pass other than what I expected).

That procedure does work here, and I've opened the "sub-PR" cruessler#1 to offer the regenerated archive from running it, in case you find that useful. (As noted there, regenerating the archive allows all CI checks to pass, as can be verified in EliahKagan@e9ff5de.)

@Byron
Copy link
Copy Markdown
Member

Sebastian Thiel (Byron) commented Jan 11, 2026

Yes, I think what Eliah Kagan (@EliahKagan) shared would be the fix to this. The key here is to remove gix/tests/fixtures/generated-do-not-edit which serves as local cache, per crate, and while it exists it won't regenerate the TAR file.
Not all tar files are portable, and if they are not they need to be mentioned in the .gitignore so they won't be generated at all. But the one added here definitely is.

Edit: I also put it back to draft as long as CI is unhappy.

@Byron Sebastian Thiel (Byron) marked this pull request as draft January 11, 2026 07:41
Done by running

    gix clean -xde
    cargo nextest run --workspace --no-fail-fast

on an Ubuntu 25.10 system, and verifying that all tests passed and
that exactly one non-`.gitignore`'d archive was regenerated.
@cruessler Christoph Rüßler (cruessler) marked this pull request as ready for review January 11, 2026 14:54
@cruessler
Copy link
Copy Markdown
Contributor Author

Eliah Kagan (@EliahKagan) Sebastian Thiel (@Byron) Thanks a lot to both of you for your help! I think I’m now closer to understanding how generated archives and their caches work. :-) The thing I wasn’t aware of was that I had to delete the …/generated-do-not-edit directory as it never showed up it git status’s output.

…ead of `number`

This style is used in `gix-diff` already, and I think it's minimal and easy to understand.
@Byron Sebastian Thiel (Byron) enabled auto-merge (squash) January 12, 2026 05:54
@Byron
Copy link
Copy Markdown
Member

Thanks a lot! I have altered the 'style' of the text that causes the diffs, and I hope you like it.
It's used throughout the codebase whenever the diff algorithm is manipulated to create certain hunks.

The idea is:

before
1
2
3
after
1
two
3

This way, it's clear which line is changed, it's encoded in the change.
There is also nothing that isn't needed, like line prefixes.

I'd hope we can refactor other places that can benefit from it as well.

@Byron Sebastian Thiel (Byron) merged commit 83c1dfb into GitoxideLabs:main Jan 12, 2026
30 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants