Re: What's cooking in git.git (Jan 2024, #01; Tue, 2)

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 5, 2024, 16:34 UTC
Message-ID: <xmqqo7dzoi2e.fsf@gitster.g>
In-Reply-To: <20240105085928.GA3078702@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 16 quoted lines

> On Wed, Jan 03, 2024 at 08:37:59AM -0800, Junio C Hamano wrote:
>
>> This is totally unrelated tangent, but the way "show-index" gets
>> invoked in the above loop makes readers wonder how the caller found
>> out which $idx file to read.
>> 
>> Of course, the above loop sits downstream of a pipe
>> 
>>     find .git/objects/pack -type f -name \*.idx
>> 
>> which means that any user of "git show-index" must be intimately
>> familiar with how the object database is structured.  I wonder if we
>> want an extra layer of abstraction, similar to how the reference
>> database can have different backend implementation.
>
> I assume you mean a test helper by "extra layer of abstraction".

Well, that might be a good first step, but I was envisioning more into far future where the object store is reimplemented on top of high-performance database, at which point we may want subcommands like "git odb list-packs" that lists packfile names (which may not name any on-filesystem files) that can be given to "git show-index", for example. Of course, the abstraction boundary of the object store might be placed a lot higher and the interface into it may be limited to "here is an oid, give me its contents" without distinction between the objects in packfiles and objects in loose object files.

> So I think we should just punt on it for now. Adding one case here is
> not making a hypothetical abstraction layer significantly harder to add
> later.

Totally agree, and that is why I labeled the whole thing as an unrelated tangent.

Thanks.