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