4

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

Felix Kling
  • 795,719
  • 175
  • 1,089
  • 1,143
agent.smith
  • 9,134
  • 9
  • 37
  • 49

1 Answers1

2

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.

Justin ᚅᚔᚈᚄᚒᚔ
  • 15,081
  • 7
  • 52
  • 64
  • *@Justin*: What u r saying completely makes sense. But I have couple of questions. 1. Does that mean users dont need to update their local superepo? I think they dont. 2.Can there be any issues when users will try to branch out in their local superepo or rebase their super repo? I am also interested to see answers from other people. Let us see what we get. – agent.smith Mar 21 '12 at 20:31
  • 1
    @agent.smith: I updated the answer in response to your comment. Regarding point 2, can you clarify: is this super-repo just a collection of submodules, or does it contain code that other people need to modify? Your original question suggests the former, but your comments make me suspect the latter. – Justin ᚅᚔᚈᚄᚒᚔ Mar 21 '12 at 20:46
  • *@Justin*: AWESOME!!! This is what I wanted. My bare repo not gonna have anything other than submodules. What I wanted was users to be in sync with each submodule update. The way I want to setup my repo must be common among other projects, in which modules gonna get updated. Is this how some one wud create a repo structure for the 'build'. Or there are any better ways to go about it. – agent.smith Mar 21 '12 at 20:59
  • With git, there are many ways to approach complex repositories. The submodule approach sounds like it would work well for your situation though. The best way to know for sure is to try it! – Justin ᚅᚔᚈᚄᚒᚔ Mar 21 '12 at 21:05