Jonathan Tan <jonathantanmy@xxxxxxxxxx> 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. Hmph, the approach taken by these two patches smells bad. When a blob is deliberately omitted with --fitler=blob:none, the fsck that encounters an entry in a tree object that is about that expected-to-be-and-actually-is-missing blob does *not* complain and that is by design, right? 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? E.g. a reference to an expected-to-be-missing blob still lets us know that the missing object is expected to be a blob, but a ref only stores the object name and not its type, so we can tell it is missing, but we cannot say it is OK to be missing because we expect it to be a blob, or something?
