> That is true; submodule.recurse is not affecting git clone. > This was a design decision once it was introduced, as the git clone might be > too large. Maybe we need to revisit that decision and just clone the > submodules if submodule.recurse is set. > > The problem that this bug report highlights, is the following: > Each branch has its own .gitmodules file and they can be all different, > however at clone time we only clone submodules from the currently active > branch. > > So you could get your test case to pass with > git clone --branch with-submodule main clone5 >
Thank you for your input Stefan. But here is our situation : 7 different projects in separate repositories Big parts of the code is similar between the projects We want to extract these similar portions in separate repositories and add them as submodules (maybe about 10 of them). We would do this progressively, adding one submodule at a time. We need to support older versions so we have to keep branches that will not have submodules. Since we need to checkout these branches regularly, we would want to have submodule.recurse enabled. With this setup, every time a submodule is added in one of the projects, each developer would get the "fatal: could not reset submodule index" error and would be unable to checkout master branch.
