Web lists-archives.com

Re: [PATCH 4/4] get_oid(): when an object was not found, try harder

Jeff King <peff@xxxxxxxx> writes:

> I'm not sure it's really worth addressing (just because I don't think
> there's a good way to do it that isn't expensive).

I do not think so, either.  Not at this layer, anyway.

If a "-x" command newly created an object whose prefix makes it
ambiguous against an existing object, we would not notice, unless we
refresh the loose object cache, that we now have two objects that
share the prefix.  And we will find an object (the older one) with
the prefix in the stale cache without hitting "oh we do not find it,
let's retry" codepath.  So to solve both sides of the coin, we'd
need invalidation either way, which obviously defeats the whole
caching concept, doesn't it?

But when we know we are running things like interactive rebase with
"-x" that (1) creates new objects while we are waiting for that
process to finish and (2) not performance critical, the loop that
drives these steps can flush any cache after seeing an external
process to return control to us.  Such an approach would still not
solve the issue a totally unrelated "repack" process creates by
mucking with the object database behind our back, but at least the
damage to the code is much better isolated ;-)