Submodule object store

[Martin Waitz <tali@admingilde.org>]

[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]