Re: Composing git repositories

[Junio C Hamano <gitster@pobox.com>]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> 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.