Ramkumar Ramachandra <artag...@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

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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to