On 02/09/2017 08:58 PM, Jeff King wrote: > On Thu, Feb 09, 2017 at 02:26:57PM +0100, Michael Haggerty wrote: > [...] >> A `files_ref_store` would be perfectly happy to represent, say, the >> references *physically* stored in a linked worktree (e.g., `HEAD`, >> `refs/bisect/*`, etc) even though that is not the complete collection >> of refs that are *logically* visible from that worktree (which >> includes references from the main repository, too). But the old code >> was confusing the two things by storing "submodule" in every >> `ref_store` instance. >> >> 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. I consider it an implementation detail of the files backend that it needs to keep a permanent record of its submodule path in files_ref_store. Some hypothetical future backend might instead need, say, an IP number and port to connect to a MySQL server. A hypothetical pure packed-refs backend might just store the path of the packed-refs file. A more likely imminent change is that backends need a path, but that the path needn't correspond to the git_dir of the repository that contains the corresponding objects, for example in the case of a linked worktree. You might ask for the ref_store for a worktree-submodule, and end up getting a compound object that delegates to one ref_store pointing at its git_dir and one at its common_dir. Michael