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@xxxxxxxxx/
[3] https://lore.kernel.org/git/20201209105844.7019-1-peter.kaestle@xxxxxxxxx/
[4] https://lore.kernel.org/git/CAN0XMOLiS_8JZKF_wW70BvRRxkDHyUoa=Z3ODtB_Bd6f5Y=7JQ@xxxxxxxxxxxxxx/t/#u
[5] https://lore.kernel.org/git/1604413399-63090-1-git-send-email-peter.kaestle@xxxxxxxxx/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
