On 6/17/2025 3:46 PM, Junio C Hamano wrote: > Jacob Keller <jacob.e.keller@xxxxxxxxx> writes: > >> From: Jacob Keller <jacob.keller@xxxxxxxxx> >> >> The remotes_remote_get_1 (and its caller, remotes_remote_get, have an >> implicit dependency on the_repository due to calling >> read_branches_file() and read_remotes_file(), both of which use >> the_repository. The branch_get() function calls set_merge() which has an >> implicit dependency on the_repository as well. >> >> Because of this use of the_repository, the helper functions cannot be >> used in code paths which operate on other repositories. A future >> refactor of the submodule--helper will want to make use of some of these >> functions. >> >> Refactor to break the dependency by passing struct repository *repo >> instead of struct remote_state *remote_state in a few places. >> >> The public callers and many other helper functions still depend on >> the_repository. A repo-aware function will be exposed in a following >> change for git submodule--helper. >> >> Signed-off-by: Jacob Keller <jacob.keller@xxxxxxxxx> >> --- >> remote.c | 58 ++++++++++++++++++++++++++++------------------------------ >> 1 file changed, 28 insertions(+), 30 deletions(-) > > As exactly one remote_state instance belongs to each repository ever > since fd3cb050 (remote: move static variables into per-repository > struct, 2021-11-17) defined the former, and remote_state is not > shared across repository, passing the repository instance that owns > a remote_state instance and pick up the .remote_state member out of > it as needed would give us the right remote_state, and gives us > access to the repository instance it owns it. > > Makes perfect sense, Yep. It looks like most of the use of the repository structure actually comes from the to-be-removed logic for handling the remotes_from_file stuff.. but I don't really want to delay these fixes and improvements to 3.0. :(
