hoi :) On Mon, Mar 26, 2007 at 03:51:21PM -0700, Junio C Hamano wrote: > I was not following the gitlink discussion closely, but what is > the motivation behind this separation of the object store? Mostly scalability. Some operations need to traverse all objects and this may be prohibitive in large repositories. So the traversal has to be split somehow to not require all objects to be loaded into RAM at the same time. The most natural separation is at the submodule level. The idea is to collect all the submodule references in the supermodule and then traverse the submodule independently with the saved references. To make purge and fsck work we have the hard requirement that it must be possible to list all objects which belong to one submodule. As modules (rightfully!) don't have any project ID, we need some other means to map submodule tree entries which are stored in the supermodule to the corresponding object store. The most simple way is to use the location of the submodule within the parent to find the submodule object store. prune and fsck can then use a path-limited commit traversal in the parent to get all relevant submodule references. And moving the submodule object store into the .git directory of the supermodule has several reasons: in bare repositories it has to be that way anyway and I don't want to loose the submodules history if the user decides to remove the submodule from his working directory. Not the entire submodule object store has to be moved this way, only that part that is referenced by the supermodule. So it can make sense to have a full .git repository in the submodule, together with another object store (handled like alternates) in the supermodule. -- Martin Waitz
Attachment:
signature.asc
Description: Digital signature