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 ;-)
