Sebastian Thiel
Sebastian Thiel
Thanks, it really looks like this is a bug where it can't properly scale beyond 32 anymore.
This issue is top of my list, and still I didn't get to it - special times. Indeed, I'd appreciate your help, thanks for asking. https://github.com/GitoxideLabs/gitoxide/blob/dbf079f4b70db01ae4f850796ae6006d45d3f99c/gix/tests/gix/remote/fetch.rs#L88-L90 The test above could...
Apologies for the long wait. However, I did change the test in the linked PR to the point where it *should* be able to reproduce the issue. The hypothesis was...
Thanks for sharing! It's good that this sounds like parallelism isn't the issue here, but merely the local state of another gix::Repository. Does that means that you'd think the following...
That is great to hear that this is a PoC which basically dialled pack creation up to 11 :)! I presume this won't happen anymore if the `gix::Repository` is re-instantiated...
Does this happen when you use `gix`? Or is this part of a long-running program?
Is there a way to reproduce this? `gix clone && gix …` maybe? Thanks again.
I think there is a couple of interleaved threads going on here :D, but to sum it up: * with `gix`, the CLI, there should be no such issue. But...
`repo.objects.store_ref().metrics().unused_slots` should do the trick. Since each non-empty fetch creates a new small pack, you should see this value go down by one each time. In theory, compacting these small...
Great, please let me know how it goes. And lastly, I recommend making reasonably sure that the newly opened repo won't be used before the old one is dropped so...