Re: [PATCH 0/5] Store submodules in a hash, not a linked list

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Feb 9, 2017, 21:23 UTC
Message-ID: <9ba16176-b388-4c70-a479-fda4c9244e67@alum.mit.edu>
In-Reply-To: <20170209195812.dbbmko4sas3wtdy5@sigill.intra.peff.net>

On 02/09/2017 08:58 PM, Jeff King wrote:

Show 18 quoted lines

> 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