"Glen Choo via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Glen Choo <chooglen@xxxxxxxxxx> > > remote.c only works with the_repository because it stores its state as > static variables. To support non-the_repository, we can use a > per-repository struct for the remotes subsystem. OK, so eventually we can hook the struct this patch introduces as a member in the repository structure, so that we can have one such struct per in-core repository instances? Will some of the component of this new structure have to be aware of the containing structure, even the repository instance the containing structure belongs to? For example, the apply_push_cas() function (there is nothing special about it---just a random example near the end of file) takes "struct remote *" which will be passed to underlying apply_cas() and the control flow eventually need to reach read_ref() via remote_tracking(). In a future world where we keep multiple in-core repositories and interact with multiple repositories in-process, this read_ref() must know in which repository it is asked to read the value of the ref. Do we expect to plumb "struct repository *" throughout the callchain, or will some of the struct types gain a backpointer to "struct remote_state", and "struct remote_state" will in turn have a backpointer to the containing repository, so that remote_tracking() can learn the ref_store it needs to use when making a call to refs_read_ref_full() to replace the current call it makes to the read_ref() function? As to the name, I do not think "remote state" is not too bad, but the word "remote" there certainly does not mean "state of a remote repository", and in that sense, it might be confusing. But It is still a seemingly random "collection of data that we need to interact with remote repositories", so in that sense, the word "remote" fits its purpose. There are pieces of information needed for a branch to interact with a remote repository, and the branches variable serves as a caching mechanism for that, for example.
