Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

View a GitIndex as of a particular commit. #178

Open
Eh2406 opened this issue Dec 6, 2024 · 1 comment
Open

View a GitIndex as of a particular commit. #178

Eh2406 opened this issue Dec 6, 2024 · 1 comment

Comments

@Eh2406
Copy link
Contributor

Eh2406 commented Dec 6, 2024

I'm in the somewhat odd position of debugging/benchmarking cargoes resolver. I have a situation like "last month resolving foo-bar = "=0.1.0" took 0.1sec but it is now taking 3sec". Sometimes we can bisect through cargo to find what changed. But, sometimes what changed is the contents of the index. Like "three days ago the transitive dependency baz was yanked, and that is what cause things to get slower". It would be really useful to be able to use cargo bisect on the git repo that's holding the index.

Describe the solution you'd like
Add a with_path_and_refspec to GitIndex that did the same as new but skipped the search in find_remote_head and just used the ref provided.

Describe alternatives you've considered
I have considered using an outside tool to modify the git repo that GitIndex is pointing to. But the thorough search done by find_remote_head makes it hard to trick the program into using the commit I want.

The Changes is another alternative. If a Change had a .crates[_parallel]() method that would also solve my needs. Or even better, the ability to convert a Change into a GitIndex.

Additional context
My debugging tool is https://github.com/Eh2406/pubgrub-crates-benchmark

@Byron
Copy link
Collaborator

Byron commented Dec 7, 2024

Thanks a lot for bringing this up! I think it makes perfect sense to make the Git based crates-index bisectable.

To me it seems the head_commit is critical in what it perceives as the current state. So being able to traverse existing commits from the head-commit and setting the head-commit should allow anyone to implement a bisect.

Also it seems like a very simple implementation unless I am missing something.

If that sounds good to you, maybe you could try it for yourself by adding a getter and setter, or by making it public entirely after removing the unnecessary head_commit_hex.

The reason I am not just implementing it myself is that it seems so trivial that I think it's beneficial if you can implement and validate the API in one go. And I am happy to help if anything else comes up.

@Eh2406 Eh2406 mentioned this issue Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants