Question

I wanna create a public repo (bare repo) which contains multiple submodules. I want different people to clone this bare repo, do the changes in any submodules. Update the public repo. However, I realized this is quite painful. I want my repo to look like below:

I have four independent repos. a.kernel b.rootfs c.apps d.modules. I combine them into one superepo called, “build”. From this superepo, I make a bare repo build.git which is shared across people.

Now if someone clones the bare repo and makes changes in the “kernel”,submodule, then he has to do following things to push the changes to the public bare repo.

1. commit it to “kernel”,repo in the local clone.
2. commit it to “build”,superepo in the local clone.
3. commit it to “kernel”, submodule in the public repo.
4. commit it to “build”, public superepo.
5. pull the changes in the build.git, public bare repo.

Doing all this is painful. It kind of defeats my purpose of bundling 4 repos into 1 superepo. Is there a better way to go about it. (I assume users who are gonna do it are trusted and are allowed to mess with anything.)

Answer 1

I’m interested to see other answers to this, but I fear that you’re overcomplicating things a bit.

It is not necessary for other developers to clone build in order to make changes to the other independent repos. Their workflow should look similar to this:

• Clone apps.
• Make changes to apps.
• Push commits up to the server.

Then, you (or better, a periodic or CI process) simply have to do a git submodule update on the build repo and then build.

Note that at no point should the developers have to commit anything to (or even touch) the build repo.

In this example, each submodule should be a completely self-contained repository. If they are not (meaning, if you have to modify build in order to apply any changes in the submodules), then they should not be submodules but rather subdirectories of build.

If the developers need to build locally, they should do the following once:

• Clone build
• Edit .gitmodules to point each submodule at their local repo
• Run git submodule sync to apply the changes to .gitmodules

Their local copy of build now points at their local copies of the submodules, rather than to the ‘blessed’ server copy. This means that they can use build to test build the entire project including their local changes without affecting the stable code on the server. But, it is not necessary (or recommended) for the users to push these changes in build up to the server. With GitHub you can prevent accidents by not adding the other developers’ public keys to the build repo.