RE: fatal: could not reset submodule index

3 messages, 2 authors, 2018-06-18 · open the first message on its own page

RE: fatal: could not reset submodule index

From: Antoine W. Campagna <hidden>
Date: 2018-06-14 18:19:35

On Wed, Jun 13, 2018 at 18:19, Antoine W. Campagna wrote:
Here is the full reproduction instructions:
Newlines got mangled, making my message hard to read. Sorry.

Here is the corrected reproduction instructions:

# Create a repository
mkdir main
cd main
git init
touch main.txt
git add main.txt
git commit -a -m "Initial commit"
cd ..

# Create a second repository
mkdir sub
cd sub
git init
touch sub.txt
git add sub.txt
git commit -a -m "Initial commit of repo sub"
cd ..

# Add the second repository as submodule, on a separate branch
cd main
git branch with-submodule
git checkout with-submodule
git submodule add ../sub sub
git commit -a -m "Add submodule"

# Set main repo back to master branch (without the submodule)
git checkout master
cd ..

# Make a clone and checkout the branch
git clone main clone1
cd clone1
git checkout with-submodule
# Submodule is not automatically updated (sub folder is empty)
git submodule update --init --recursive

37 more lines

Re: fatal: could not reset submodule index

From: Stefan Beller <hidden>
Date: 2018-06-15 19:47:28

# Trying again with submodule.recurse
git config --global submodule.recurse true
git clone main clone4 cd clone4
git checkout with-submodule
# Submodule is still not automatically updated (sub folder is empty)
# It seems like submodule.recurse does not affect git clone
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

RE: fatal: could not reset submodule index

From: Antoine W. Campagna <hidden>
Date: 2018-06-18 13:57:28

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help