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