Brandon Williams <bmw...@google.com> writes: >> the_repository -> the_object_store >> but the object store is a complex beast having different hash tables >> for the different alternates. > > After looking at the patch and some of the comments here I think that > this is probably the best approach with a few tweaks (which may be > completely unfounded because I'm not familiar with all the object store > code). > > In an OO world I would envision a single object (let's say 'struct > object_store') which is responsible for managing a repository's objects > no matter where the individual objects came from (main object store or > an alternate for that repository). And if I understand correctly the > single hash table that exists now caches objects like this.
I would say that conceptually an object-store object has an interface to answer "give me info on the object I can refer to with this object name". At the implementation level, it should have a hashtable (lazily populated) for all the objects in a single $GIT_OBJECT_DIRECTORY, grafts/replace info, and a set of pointers to other object-store instances that are its alternate object stores. You'd need to have a mechanism to avoid creating cycles in these pointers, of course.
