We are migrating to git. We have a large number of modules that make up our products, some of them are shared between products. The product is represented by a "thin" super repository (ssh://server/product.git) that only contains submodules:
[submodule "module1"]
path=module1
url=ssh://server/product/module1.git
[submodule "module2"]
path=module2
url=ssh://server/product/module2.git
...
I can clone the super repository and work with the submodules and commit them, and then commit the submodules to the super repository.
The problem comes when I want to introduce another tier. There are two basic scenarios (this can combine to make more complex setups, but anything should be a combination of these):
As a developer, I clone a central repository and work. Then I want to submit my code to our continuous integration server before merging my changes to the central repository. I let the CI server clone my repo. This doesn't work, the CI server will clone my super repo and then it will clone the submodules from the central repository location (since that is what it says in .gitmodules).
As a team we want to have an integration repository that we work towards before we, at the end of a sprint, merge our code to the central repository. This fails, for the same reason.
I tried specifying relative URLs for the submodules, but this doesn't work, either, since when we clone the second tier into the third tier the relative URLs resolve relative to the second tier repository location, but the second tier submodule locations are inside the second tier super repository.
Can I have it both? Git submodules and n-tier repository structure?