Re: Local Config File: Submodule initialization looks broken with the --recurse-submodules option when cloning a repository

From: Ron <ronazek@protonmail.com>
Date: Oct 15, 2019, 00:39 UTC
Message-ID: <XqdveI1_zW78uGKUxGnJanJ87mg_lJaw9tKylbfgadEeKlVUlOx5juZWpXC0OPDC4lD60mbRTHDm64HqP1Jxw-A9byDF9le2YfuECuatGQk=@protonmail.com>
In-Reply-To: <ZkLbpInDB0A-uWL3lVcy67PplIX56Pr7qakiHnXnP4OInRFs20ZPH3wDZl-LNoCNRv-_4HlTwa9LLkrWjdVFPshEi-JXVAhHwsLdp2ivJew=@protonmail.com>

Show 11 quoted lines

> I've got someone to test this with the latest 2.23.0 version on archlinux.
>
> It is still happening:
>
> git clone --depth=1 --recurse-submodules --origin upstream https://github.com/git-for-windows/git;
> git -C git config --get submodule.active
> expected true, got .
>
> Anything more I need to add to help this get solved?
>
> Sent with ProtonMail Secure Email.

This appears to have been a false positive, there are 2 different kind of "active" parameters in the config file and this is, according to the docs, expected behavior. I'm not sure if the other tester wrote the last line himself or did git wrote that for him, because on GFW that command only outputs the value if there is one.

I cannot reproduce the error anymore that I thought was happening because of this, it never caused a problem when cloning or when applying submodule later, it must have been a coincidence at the time.

The effect is "equivalent" as the docs say, whether doing "--recurse-submodule" (without specifying pathspec) at clone time or doing a normal clone and running "git submodule update --init --recursive" afterward, but technically the config file will not be the same.

Sorry for the inconvenience.