Re: [PATCH 0/2] Avoiding errors when partial cloning a tagged blob
- Date: Fri, 06 Jul 2018 13:10:59 -0700
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [PATCH 0/2] Avoiding errors when partial cloning a tagged blob
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?