repo.odb()
.context("Failed to get the repo's object database")
.unwrap()
.add_new_mempack_backend(999)
.context("Failed to create new mempack ODB backend")
.unwrap();
So I'm immediately dropping the returned Odb. I had trouble understanding the underlying C code in libgit2, so my first question is:
Assuming I never explicitly set an alternative ODB, should repeated calls to repo.odb() ultimately point to the same underlying resource in "C land"?
Secondly, I've observed that if I create a mempack backend like this and then write things to the repository (trees, blobs) then most of the time they never get written to disk (good) but occasionally they do (intermittent, bad!)
So my next question is:
Is there an obvious explanation for this — e.g. am I supposed to be keeping the Odb alive to stop the mempack backend from (eventually?) being removed/destroyed?
I'm hoping I've just misunderstood something simple about mempack usage. 🙏
I have some code like this in a function:
So I'm immediately dropping the returned
Odb
. I had trouble understanding the underlying C code in libgit2, so my first question is:Assuming I never explicitly set an alternative ODB, should repeated calls to
repo.odb()
ultimately point to the same underlying resource in "C land"?Secondly, I've observed that if I create a mempack backend like this and then write things to the repository (trees, blobs) then most of the time they never get written to disk (good) but occasionally they do (intermittent, bad!)
So my next question is:
Is there an obvious explanation for this — e.g. am I supposed to be keeping the
Odb
alive to stop the mempack backend from (eventually?) being removed/destroyed?I'm hoping I've just misunderstood something simple about mempack usage. 🙏
Thanks!