Re: issue with git submodules and a clone.defaultRemoteName different than origin?

[Jacob Keller <jacob.e.keller@intel.com>]

On 6/4/2025 10:18 AM, Jacob Keller wrote:
> 
> the parent project already has a URL in its config. What if we updated
> the logic to just directly use that URL instead of using a remote name?
> Or at the very least, we try to pick a remote based on the URL.
> 

I'm looking into this approach still, but I ran into some interesting
issues with the remote.c logic which claims to work with any "struct
repository *", but ends up calling paths to that hard code the_repository.

It looks like those end up in the "read_remotes_file" and
"read_branches_file" functions which are deprecated, and planned to be
removed in 3.0...

Would patches to modify those to take a repository pointer in order to
allow callers of read_config() to work properly with a submodule
repository be acceptable?

I also saw that many functions take a remote_state structure, but if I
wanted to make them submodule repo compatible I would need to either add
or switch to passing a repo pointer. I'm not sure what the best method
for that is. Add parameters? We can get from repo to remote_state easily
but we can't go back, so it seems like just switching them to take repo
instead of remote_state would be sufficient.

I wanted to use the remote.c helpers rather than re-inventing the logic
for reading the config to figure out remotes, both a) to find the
correct remote by its URL and b) to find out if there is exactly 1 remote.