You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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 dependencybaz
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
toGitIndex
that did the same asnew
but skipped the search infind_remote_head
and just used theref
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 byfind_remote_head
makes it hard to trick the program into using the commit I want.The
Changes
is another alternative. If aChange
had a.crates[_parallel]()
method that would also solve my needs. Or even better, the ability to convert aChange
into aGitIndex
.Additional context
My debugging tool is https://github.com/Eh2406/pubgrub-crates-benchmark
The text was updated successfully, but these errors were encountered: