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

[Philippe Blain <levraiphilippeblain@gmail.com>]

Hi Johannes, Gábor, Aleksey,

Le 2019-10-25 à 08:41, Johannes Schindelin a écrit :
> 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.

I agree, and this regression was fixed recently by Peter Kaestle.
This bug was in fact reported twice recently ([1], [2]) and fixed
earlier this month [3] (full threads: [4], [5]). The patch series is currently cooking
in the 'next' branch [6]. You can check out just the fix from [7].
It should be included in Git 2.31.

Cheers,

Philippe.

[1] https://lore.kernel.org/git/op.0vvmwohypvqxoc@damia/
[2] https://lore.kernel.org/git/1604413399-63090-1-git-send-email-peter.kaestle@nokia.com/
[3] https://lore.kernel.org/git/20201209105844.7019-1-peter.kaestle@nokia.com/
[4] https://lore.kernel.org/git/CAN0XMOLiS_8JZKF_wW70BvRRxkDHyUoa=Z3ODtB_Bd6f5Y=7JQ@mail.gmail.com/t/#u
[5] https://lore.kernel.org/git/1604413399-63090-1-git-send-email-peter.kaestle@nokia.com/t/#u
[6] https://github.com/git/git/blob/730f2a8a60960c30a79e00ebe034836f60befbf0/whats-cooking.txt#L765-L771
[7] https://github.com/gitster/git/tree/pk/subsub-fetch-fix-take-2