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.
