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

From: Jacob Keller <jacob.e.keller@intel.com>
Date: Jun 6, 2025, 21:29 UTC
Message-ID: <bdf7e50f-aa65-4514-b147-9f7ebed147ab@intel.com>
In-Reply-To: <48c2af0f-348a-4443-a8b7-74ea4b666bff@intel.com>

On 6/4/2025 10:18 AM, Jacob Keller wrote:

Show 5 quoted lines

> 
> 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.