From: Philippe Blain Date: Fri, 01 Jan 2021 15:42:52 GMT Subject: Re: Issue: "Could not access submodule" error when pulling recursively with Git 2.22.0 Message-ID: In-Reply-To: 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