We have a git repository that includes various submodules. There is an old clone of the main repo, on which we reproducibly get the following error when running git fetch:
fatal: remote error: upload-pack: not our ref a63912a948cf1ce4c700c16b3417e89287f61f63
fatal: git upload-pack: not our ref a63912a948cf1ce4c700c16b3417e89287f61f63
When running git fetch a second time after this, the error disappears.
My current assumption is that the old clone (or some branch being fetched) contains references to commits in submodules which for whatever reasons (rebases?) have disappeared from origin. I understand that this can happen but how can I find the specific dangling reference, so that I can fix it?
The old clone sits in a base image that we use for setting up tests, so I can perfectly reproduce the error even if it is gone on each second attempt. However, I am reluctant to just ignore the problem by littering our scripts with git fetch || git fetch or similar hacks.
So how can I find out which commit in the main repo references the missing ref a63912...
More generally, is there a way to perform an integrity check on a repo that can catch these errors upfront?
--no-recurse-submodulesand then with--recurse-submodules, though that's barely better than just trying twice. I believe the reason the fetch succeeds the second time is that the fetch of the parent repo actually completed, so upon rerun it doesn't encounter the invalid ref. If that is indeed what's happening, it's certainly confusing. – Hoopen