Bypass shallow clone support for in-memory repositories #6684
Conversation
|
@ethomson - The failed test looks like it's an online test detecting a memory leak - I've no idea how I'd have possibly achieved that for just one of the test runs - Is there possibly another intermittent issue at play here with the online tests? |
Yes - some of the integration tests that require network connectivity are flaky (as a result of flaky networking, etc). And when we fail quickly out of a test, we will leak memory, which Valgrind shows. I haven't found a good way to really get right with this - in particular, that Windows SHA256 gitdaemon test seems to fail quite frequently. I suspect that there's an underlying bug, either on our side or in the gitdaemon. 🤔 In any case - that's unrelated to this PR. 😁 Apologies for the noise. |
I agree. I don't know what this looks like (yet) but it's something that we need to figure out. |
|
In the meantime, thanks for the fix! |
Handles case where determining path to grafts files for shallow clones may fail with 'path cannot exist in repository' for an in-memory repository that doesn't have any directories.
To cater for this, empty grafts are created/set on the repository, and if they're already set, are refreshed upfront rather than attempting to derive the path again.
This change is not intended to support shallow clones for in-memory repositories, rather it's intended to preserve prior behavior where we can at least still perform a full clone for an in-memory repository with a custom database backend, without any files stored on-disk.
If a shallow clone were attempted in this scenario, it's likely/expected to fail when attempting to write grafts to file at the end of the clone. Recommend consideration be given to implementing support for custom grafts backends, or more generally, a virtual file system layer to support custom backends for storing misc. files.