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

Initially reported for GFW on version 2.20.1, I have tested with Linux Mint Mate 19.1 Tessa which by default uses git version 2.17.1

It produces a config file with the relevant submodule entries looking like this:

----------------
[submodule]
	active = .

[submodule "Submodule/Path"]
	url = https://github.com/organization/submodule.git
----------------

Instead of that, which is produced by manually initializing a submodule anytime after cloning:

----------------
 [submodule "Submodule/Path"]
	active = true
	url = https://github.com/organization/submodule.git
----------------

Sent with ProtonMail Secure Email.

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.