On 25/05/26 07:45AM, Patrick Steinhardt wrote: > On Thu, May 22, 2025 at 05:13:55PM -0500, Justin Tobler wrote: > > On 25/05/14 07:12AM, Patrick Steinhardt wrote: > > > The `object_directory` structure is used as an access point for a single > > > object directory like ".git/objects". While the structure isn't yet > > > fully self-contained, the intent is for it to eventually contain all > > > information required to access objects in one specific location. > > > > > > While the name "object directory" is a good fit for now, this will > > > change over time as we continue with the agenda to make pluggable object > > > databases a thing. Eventually, objects may not be accessed via any kind > > > of directory at all anymore, but they could instead be backed by any > > > kind of durable storage mechanism. While it seems quite far-fetched for > > > now, it is thinkable that eventually this might even be some form of a > > > database, for example. > > > > > > As such, the current name of this structure will become worse over time > > > as we evolve into the direction of pluggable ODBs. Immediate next steps > > > will start to carve out proper self-contained object directories, which > > > requires us to pass in these object directories as parameters. Based on > > > our modern naming schema this means that those functions should then be > > > named after their subsystem, which means that we would start to bake the > > > current name into the codebase more and more. > > > > > > Let's preempt this by renaming the structure to `odb_alternate` now > > > already. This name is agnostic of how exactly objects are stored while > > > still specifically pinpointing that this is about an alternate object > > > database. Furthermore, it is already used in Git to represent this > > > context -- the only stretch is that the primary object directory is now > > > the primary alternate. > > > > I know the naming here has been discussed in other threads, but > > `odb_alternate` doesn't feel quite right to me. When I think of an > > object database alternate, I think of the additional object sources that > > may be configured for a repository. > > > > From my understanding, the `odb_alternate` here applies to any object > > source, even the main one. Using "alternate" makes me think there is > > another object database somewhere which may be confusing in scenarios > > where there would only be one. > > Yeah, I do get that. On the other hand I don't think it's too much of a > stretch: the local object directory of one repository is another repo's > alternate. Ok, I was only thinking about this from the perspective of the repository we would be operating in. But I can sort of see how any odb can be an alternate from the perspective of a different repository. > Furthermore, we already do have the distinction between > "local" and "non-local" objects, which translates quite well into this > new naming schema. Just to clarify, are you referring to how we differentiate between local and alternate odbs? I'm not quite sure I fully understand. > > > Ultimately I don't want to bikeshed too much on names, but wanted to > > voice my thoughts. As an alternative to "alternate", maybe we could do > > `object_source`? :) > > If we were picking something more "generic" I'd favor `odb_backend` over > `object_source`, to be honest. But we have agreed in the previous > version of this patch series that this isn't the way to go. > > So I'm not quite convinced that `object_source` is better, and if we > were to go this way I'd also rather call it `odb_source`. If others > agree that `odb_source` is better than `odb_alternate` I'm happy to > adapt. But until then I'd rather leave things as-is. That's fair. Between `odb_backend` and `odb_alternate`, I would probably still prefer the former, but ultimately I'll acclimate to whatever is choosen. :) -Justin
