> Shouldn't the recursive clone pick up the HEAD of the submodule branch? No, because a submodule is a specific reference to a commit of another repository. > If it sounds like we don't quite understand what git is doing here, that's a fair statement ;-) No problem :-D, in fact, the idea of submodules is quite simple: there's this .gitmodules files where the submodule metadata is stored, and there's an entry mapping the name of the submodule to its commit inside each commit of the parent repository. As a public example we have the Git source code, which has a submodule. You can clone it with: git clone https://github.com/git/git.git I'm working with the current master of that repository, which today is at the commit 5b97a56. As I said before, this repository has a submodule called sha1collisiondetection. Supposing that you're inside the Git repository, if you run: git rev-parse 5b97a56:sha1collisiondetection you'll get this hash: 855827c. This is the hash commit of the submodule at the commit 5b97a56 of the parent repository. Note that I checked this without touching the submodule itself, as this information is stored in the parent repository. You can do that for any commit. For example, if you run for 23e37f8: git rev-parse 23e37f8:sha1collisiondetection you'll see that 23e37f8 references another submodule commit. You can even see the log of submodule reference changes: git log -- sha1collisiondetection > but it sounds like git internally stores the commit hash instead? Yes! > - We've found that the problem is avoided if we execute the following command *after* doing the recursive > clone. Not sure why this is necessary -- shouldn't the recursive clone handle that on its own? > > git submodule update --remote --recursive Sorry for answering you this out of the order, but it makes more sense to answer here. This command will checkout the submodule to the latest commit of the branch that is in the branch field of the .gitmodules (in your case, `staging`, or in my case of the Git source code, `master`). Going back to my example, let's first initialize the submodule, which I didn't before: git submodule update --init --recursive Then, run your command: git submodule update --remote --recursive This will bring the latest commits of the branch `master` of the submodule. Now, if you run: git status you'll see that the submodule has changed. This is because it is in a commit that is not the one referenced by the HEAD of the parent repository. Just like a file that was changed and not committed. And again, just like a file, if you want the repository to point to that commit from now on you'll need to: git add sha1collisiondetection git commit -m "Update the submodule" > - It sounds like you're suggesting that we need to go into the submodule and manually checkout a specific commit? Yes, or you can use git submodule update like you were doing, both work. But keep in mind that it will leave that in a unstaged state. If you want to keep it, you'll need to commit that submodule reference change. In conclusion, think of submodules as dependencies with fixed versions, where each version change needs to be commited in the parent repository. > Thanks again for your help! You're welcome! I hope that it helps you!
