Patrick Steinhardt <ps@xxxxxx> writes: > On Fri, May 23, 2025 at 07:16:04PM -0700, Junio C Hamano wrote: >> * ps/midx-negative-packfile-cache (2025-05-20) 2 commits >> - midx: stop repeatedly looking up nonexistent packfiles >> - packfile: explain ordering of how we look up auxiliary pack files >> >> When a stale .midx file refers to .pack files that no longer exist, >> we ended up checking for these non-existent files repeatedly, which >> has been optimized by memoizing the non-existence. >> >> Will merge to 'next'? >> source: <20250520-pks-pack-avoid-stats-on-missing-v2-0-333c5217fb05@xxxxxx> > > I wanted to send one more iteration of this where I hide the ugliness of > `(void *)(intptr_t)-1` behind a macro, as suggested. But I saw that > Taylor has built on top of these patches, so I don't want to make his > life harder. Cc'd him. Yeah, I do not think I've merged Taylor's work anywhere yet, but I did notice that it was built on top of this topic. I think it is perfectly OK to clean it up before your topic hits 'next'; adjusting to such a change is a responsibility of the author of a topic that depends on anything not in 'next' yet. > I think the only outstanding discussion is whether to name things > `odb_alternate` or `odb_source` [1]. In case others agree that > `odb_source` is a better name I'm happy to revise, but if not I'd rather > keep it as-is. The model in which the term "alternates" was born is "A repository has its own object directory, the primary one, and in addition it can borrow from zero or more alternate object directories that are used by other repositories". The presence of the primary makes the word "alternate" meaningful. Is the model now "A repository has one object store, which consists of one or more X, all of which are equals"? If there is no primary that is more special than others, then calling X an "alternate" may indeed sound funny, although (1) I do not find it terribly confusing and (2) I do not find "source" much better, either. The names we use to call the collection and the underlying implementations of the collection in the reference world unfortunately does not quite help to guide us, as we do not take two implementations and compose into one unified view, which is what we are doing in the object store. Hmmm... We call pathspec elements given on the command line collectively a pathspec. "Object store elements like loose object directories and packfiles form the object store"? That may be a mouthful. I dunno.
