Jonathan Tan [off-list ref] writes:

When upload-pack receives a request containing "have" hashes, it (among
other things) checks if the served repository has the corresponding
objects. However, it does not do so with the
OBJECT_INFO_SKIP_FETCH_OBJECT flag, so if serving a partial clone, a
lazy fetch will be triggered first.

OK.  

Fixing issues hit by real users reactively is a necessary and good
thing, but this is not the first time we patch callers of
has_object_file() for this kind of "we are merely trying to
determine the boundary of what we have, so that we know what we need
to add to this repository" queries, I am afraid.

Perhaps it is a good idea to sweep all the hits from "git grep -e
has_object_file \*.c" and audit the codebase to see if there are
other problematic ones?

For example, list-objects.c::process_blob() tries to if the object
exists when --exclude-promisor-objects is in effect so that it can
return early if the object is missing and it is a promisor object.
I would imagine that we would not want to lazy-fetch the object in
this case.

Thanks.  Will queue.