Jonathan Nieder <jrnieder@xxxxxxxxx> writes: >>>> When cloning a repository with a tagged blob (like the Git repository) >>>> with --filter=blob:none, the following message appears: >>>> >>>> error: missing object referenced by 'refs/tags/junio-gpg-pub' >>>> >>>> and the resulting repository also fails fsck. > [...] >> Naïvely, I may expect fsck to follow the >> same principle--when it encounters a reference to an object that is >> deliberately missing, refrain from complaining, regardless of the >> place the offending reference was found, be it inside a tree object >> or a ref. >> >> Perhaps that line of consistent behaviour may be impossible due to >> the way the reference is stored inside a tree object and a ref? > > Yes, exactly. I believe this is why we did not treat refs as > promisors when we introduced promised objects. > > We could revisit that decision and make refs into promisors, storing > any extra metadata on the side. That would be a more invasive change > than this series does, though. In the model used today, where refs > are not promisors, this series is the logical thing to do. I think that refs in files-backend is a bit hard to update to annotate with extra information like "is this merely promising or a tip of the connectivity graph?" and agree that we should not make refs promisors. Such an otherwise unreferenced blob could be made into a promised object by the promisor repository, though, I think. It can include a synthetic tree that points at such a blob in the pack stream data if it knows that the resulting pack will be marked with the .promisor bit, and by doing so, there is no need to update the client side, no?
