[PATCH 2/2] odb/source-loose: fix existence checks for newly written objects

The loose object source maintains a cache of object IDs that it uses to answer existence checks fast. This cache is lazily populated: whenever we are asked about a specific object ID, we scan the whole sharding directory it would live in and populate the cache with the objects we find. Subsequent existence checks are then answered from the cache without hitting the filesystem.

But when writing a new loose object we don't update that cache. That's fine in the case where the cache for its sharding directory has not yet been populated, because we would then populate it on a subsequent read and thus surface the newly written object. But when it _is_ populated already, then any subsequent existence check will claim that the object does not exist at all until the cache is flushed.

This issue can cause git-merge(1) to die in a partial clone because we try to fetch an object that we have just written, as reported in [1]:

  1. `prefetch_for_content_merges()` performs quick existence checks for
     all blobs that need a content merge to figure out which ones need
     to be fetched from the promisor remote. These lookups populate the
     loose object cache for the respective sharding directories.

  2. We lazily fetch the missing blobs, which writes a new packfile.

  3. We perform the merge and write the resulting blobs as loose
     objects. The cache is not updated, so for all blobs whose sharding
     directory was populated in (1), the object existence checks will
     fail.

  4. When checking out the merge result, `prefetch_cache_entries()`
     performs existence checks for all index entries that need to be
     written to the worktree. But due to the stale cache, the merged
     blobs are reported as missing, and consequently we try to fetch
     them from the promisor remote. This fetch fails because the remote
     will most likely not have them.

This issue bisects to 5946a564cdd (odb/source: make `read_object_info()` function pluggable, 2026-03-05), because in that commit we stopped flushing the loose object cache when we try to read a missing object. That was done intentionally though: a failing read is only retried when it is a non-QUICK read, whereas the cache only affects QUICK reads. So flushing the cache for a non-QUICK read wouldn't ever cause us to find that object.

So the logic described here only ever worked by chance, as the cache was incoherent after writes even before that commit. It only used to work because of the interleaving sequence of QUICK and non-QUICK reads: when we read the lazily-fetched blobs in (3) via a non-QUICK read, the first read fails because the new packfile has not yet been added to the "packed" source. On the retry we then used to flush the loose object cache, and that in turn means that the subsequent existence check in (4) rescanned the sharding directories and found the merged blobs.

We could in theory fix this by flushing all the loose object caches again, like we used to do before 5946a564cdd. But that wouldn't address the root cause: the cache would still be stale unless somebody does a non-QUICK read for a missing object. Instead, fix the bug by updating the cache whenever we write a new loose object.

[1]: <yrjh1p92qc7w.fsf@pohly-mobl1.fritz.box>

Reported-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 odb/source-loose.c       | 30 +++++++++++++++++++++++++++---
 t/t5616-partial-clone.sh | 43 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 70 insertions(+), 3 deletions(-)