Re: Composing git repositories

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 26, 2013, 16:39 UTC
Message-ID: <7vmwtqt8rs.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0=CsuAWQwk5Guf0pbC4_ZEoZiwQpamcRvBGz5LJ0QGKHg@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 6 quoted lines

> Apart from the implementation glitches, I don't like the design;
> submodules don't compose well:
>
> 1. There's an inherent asymmetry between the superproject and each of
> the subprojects, because the superproject owns all the object stores.
> Why is it absolutely necessary to relocate the object stores?

Imagine doing "git checkout oldbranch" in the superproject when your current branch has a submodule A bound to it, but the oldbranch that is an old version of the superproject did not (yet) have it.

You obviously want the directory A disappear, but you would be unhappy if you have to lose A/.git and everything in it while doing so. If you are lucky, you can re-clone, but you may have your own changes.

So you have to stash it somewhere. We could have made it to move them to $HOME/.safeplace or somewhere totally unrelated to the superproject. So in that sense, the repositories are *not* owned by the superproject in any way. However, you are working within the context of the superproject on the submodule after all, and somewhere under $GIT_DIR/ of the superorject is not too wrong a place to use as such a safe place.

> 3. The current implementation only allows me to compose with commit
> objects, but what if I want to compose with refs?  ie. What if I want
> to track the tip of the 'master' of a submodule in a superproject?

Look for floating submodules in the list archive.