On 6/16/2025 7:58 PM, Lidong Yan wrote:

Jacob Keller [off-list ref] writes：

quoted

From: Jacob Keller <redacted>

The repo_get_default_remote() function in submodule--helper currently
tries to figure out the proper remote name to use for a submodule based
on a few factors.

First, it tries to find the remote for the currently checked out branch.
This works if the submodule is configured to checkout to a branch
instead of a detached HEAD state.

In the detached HEAD state, the code calls back to using "origin", on
the assumption that this is the default remote name. Some users may
change this, such as by setting clone.defaultRemoteName, or by changing
the remote name manually within the submodule repository.

As a first step to improving this situation, refactor to reuse the logic
from remotes_remote_for_branch(). This function uses the remote from the
branch if it has one. If it doesn't then it checks to see if there is
exactly one remote. It uses this remote first before attempting to fall
back to "origin".

To allow using this helper function, introduce a repo_default_remote()
helper to remote.c which takes a repository structure. This helper will
load the remote configuration and get the "HEAD" branch. Then it will
call remotes_remote_for_branch to find the default remote.

Just a thought: since repo_default_remote() is only used within
repo_get_default_remote(), and the two have very similar names,
do you think it might be clearer to inline the former into the latter?

I will try to rename this function, but I think in context it makes
sense to keep a separate function in remote.c which does the generic-ish
stuff while the submodule--helper.c function does the submodule-specific
stuff. This is because the later patches add the URL look up support to
this function.