Re: Issue: "Could not access submodule" error when pulling recursively with Git 2.22.0

> Hi Gábor,
> 
> On Wed, 23 Oct 2019, SZEDER Gábor wrote:
> 
>> On Wed, Oct 23, 2019 at 07:22:12AM +0000, Aleksey Mikhaylov wrote:
>>> "Could not access submodule" error when pulling recursively with Git 2.22.0.
>>> This issue causes if there is submodule in submodule.
>>
>>> Please use my simple test repository to reproduce the problem:
>>> https://github.com/agmikhailov/example2361.git
>>>
>>> It is just an empty repository with one submodule (https://github.com/agmikhailov/example2361M1.git)
>>> and one submodule of submodule (https://github.com/agmikhailov/example2361M2.git):
>>>
>>> git clone https://github.com/agmikhailov/example2361.git
>>> cd example2361/
>>> git submodule init
>>
>> According to the docs of 'git submodule init', it "initializes the
>> submodules recorded in the index".  Therefore, it can only initialize
>> the submodule in 'example2361M1', because at this point we have no
>> idea that there is a nested submodule in there.
>>
>>    $ git submodule init
>>    Submodule 'example2361M1' (https://github.com/agmikhailov/example2361M1.git) registered for path 'example2361M1'
> 
> Indeed, `git submodule init` is not recursive.
> 
>>> git submodule update
>>
>> This command clones 'example2361M1':
>>
>>    $ git submodule update --recursive
>>    Cloning into '/tmp/example2361/example2361M1'...
>>    Submodule path 'example2361M1': checked out '6a9be24a1c0ebd44d91ae4dcf1fd62580b936540'
>>
>> Only at this point can we finally see that there is a nested
>> submodule, and can initialize and clone it with:
>>
>>    $ cd example2361M1
>>    $ git submodule init
>>    Submodule 'example2361M2' (https://github.com/agmikhailov/example2361M2.git) registered for path 'example2361M2'
>>    $ git submodule update
>>    Cloning into '/tmp/example2361/example2361M1/example2361M2'...
>>    Submodule path 'example2361M2': checked out '9ed39cf1fe0a8cf34e72d2e7ebff1ea9d4a63ac1'
> 
> I concur.
> 
>>> git pull --recurse-submodules=true
>>
>> And after that:
>>
>>    $ cd ../..
>>    $ git pull --recurse-submodules=true
>>    Fetching submodule example2361M1
>>    Fetching submodule example2361M1/example2361M2
>>    Already up to date.
> 
> Yes, I agree that _probably_ what the user wanted is to initialize the
> submodules recursively.
> 
> Having said that, I vaguely remember that e.g. Boost has this insane
> forest of submodules, and I am almost certain that no sane person wants
> to clone them all. _I_ wouldn't.
> 
>>> ACTUAL RESULT
>>>
>>> "git --recurse-submodules=true" command fails with message "Could not access submodule":
>>>
>>> $ git --recurse-submodules=true
>>> Fetching submodule example2361M1
>>> Could not access submodule 'example2361M2'
>>>
>>> EXPECTED RESULT
>>>
>>> All submodules are successfully updated by "git --recurse-submodules=true" command.
>>>
>>> ADDITIONAL INFORMATION
>>>
>>> Git version 2.20.1 does not have this problem.
>>> So we had to downgrade Git to work with submodules.
>>
>> The behavior was indeed different with v2.20.1, but that version
>> didn't show the behavior you expected.  When running your commands
>> with v2.20.1 I get:
>>
>>    $ ~/src/git/bin-wrappers/git pull --recurse-submodules=true
>>    Fetching submodule example2361M1
>>    Already up to date.
>>    $ find example2361M1/example2361M2/
>>    example2361M1/example2361M2/
>>
>> So while that 'git pull' didn't error out, it didn't even look at the
>> nested submodule, which is still uninitialized and empty.
> 
> I would actually argue that this is what is expected: the entire _point_
> of submodules is that they can be inactive.
> 
> Coming back to the Boost example, what I would want Git to do when only
> a fraction of the submodules is active is to skip the inactive ones
> during a `git pull --recurse-submodules=true`.
> 
> Which v2.20.1 apparently did, and I would call the current behavior a
> regression.