This issue expands on#1058

My current setup is the following: a superrepo, whose default branch ismain, and 4 submodules, 2 of which have default branchmain (just like the superrepo), and 2 of which havemaster as their default branch.

My .gitmodules file looks like this:

[submodule "submodule-a"]path = submodule-aurl = <remote URI>[submodule "submodule-b"]path = submodule-burl = <remote URI>[submodule "submodule-c"]path = submodule-curl = <remote URI>branch = master[submodule "submodule-d"]path = submodule-durl = <remote URI>branch = master

When I clone without initializing the submodules, and subsequently run

repo.submodule_update(recursive=True,init=True,force_reset=True)

I get the equivalent behaviour ofgit submodule update --init --recursive,but it still prints theFailed to checkout tracking branch refs/heads/master warning. So far, so good.

Now, in theory, running

repo.submodule_update(recursive=True,init=True)

should behave equivalently togit submodule update --init --recursive --remote, but it ends up in a state like described in#1058.

As I commented on the issue above, I could get around this issue by "correctly" initializing my .gitmodules file first by running

git submodule set-branch -b main submodule-agit submodule set-branch -b main submodule-b

For issue#1058, this is still a valid comment (hence my posting it there), as it's unlikely that the default branch isdevelop and it's likely that the superrepo branch differs from the submodule's.

Note, however, that in my use-case the superrepo's and the "incorrectly configured" submodules' branches match (main, which is very common), yet it still spits out the warning above at best and leaves you in an inconsistent state at worst.

Proposed enhancement: If the submodule config does not provide a branch explicitly, the ref to check out should be the default branch of the submodule remote, or, if that is unknown information, the default branch of the superrepo. Thus, there's a priority of refs to try out:

• branch mentioned explicitly in .gitmodules entry
• default branch of remote
• default branch of superrepo's remote
• current behaviour as last resort fallback