On 02/10/2017 01:40 AM, Jeff King wrote: > On Thu, Feb 09, 2017 at 10:23:35PM +0100, Michael Haggerty wrote: > >>>> So push the submodule attribute down to the `files_ref_store` class >>>> (but continue to let the `ref_store`s be looked up by submodule). >>> >>> I'm not sure I understand all of the ramifications here. It _sounds_ like >>> pushing this down into the files-backend code would make it harder to >>> have mixed ref-backends for different submodules. Or is this just >>> pushing down an implementation detail of the files backend, and future >>> code is free to have as many different ref_stores as it likes? >> >> I don't understand how this would make it harder, aside from the fact >> that a new backend class might also need a path member and have to >> maintain its own copy rather than using one that the base class provides. > > Probably the answer is "I'm really confused". > > But here's how my line of reasoning went: > > Right now we have a main ref-store that points to the submodule > ref-stores. I don't know the current state of it, but in theory those > could all use different backends. > > This seems like it's pushing that submodule linkage down into the > backend. > > But I think from your response that the answer is no, the thing that is > being pushed down is not the right way for the main ref store and the > submodules to be linked. In fact, there is no reason at all for the > main ref store to know or care about submodules. Anybody who wants to > know about a submodule's refs should ask the hashmap. That's correct; the main ref store and submodule ref stores know nothing of each other. Michael