Re: [PATCH 4/6] introduce a commit metapack

From: Shawn Pearce <spearce@spearce.org>
Date: Jan 31, 2013, 17:03 UTC
Message-ID: <CAJo=hJv0aqLpitnRJ6WKdPCETT6YgX5Njpv44DAYUg_KALhf=g@mail.gmail.com>
In-Reply-To: <7vboc6mzpf.fsf@alter.siamese.dyndns.org>

On Wed, Jan 30, 2013 at 7:56 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 26 quoted lines

> Jeff King <peff@peff.net> writes:
>
>>>From this:
>>
>>> Then it will be very natural for the extension data that store the
>>> commit metainfo to name objects in the pack the .idx file describes
>>> by the offset in the SHA-1 table.
>>
>> I guess your argument is that putting it all in the same file makes it
>> more natural for there to be a data dependency.
>
> It is more about the "I am torn on this one" I mentioned earlier.
>
> It would be more "logical" if this weren't tied to a particular
> pack, as the properties of a commit you record in this series do not
> depend on which pack the commit is in, and such a repository-global
> file by definition cannot be inside anybody's .idx.
>
> But if we split the information into separate pieces and store one
> piece per .idx for implementation reasons, it is crazy not to at
> least consider it a longer term goal to put it inside .idx file.
>
> Of course, it is more convenient to store this kind of things in a
> separate file while experimenting and improving the mechanism, but I
> do not think we want to see each packfile in a repository comes with
> 47 auxiliary files with different suffixes 5 years down the road.

Arrrrgggh.

Right now we are in the middle of refactoring the JGit reachability bitmap implementation to store it into a separate file and get it out of the .idx file. This work is nearly completed. So this thread is great timing. :-)

I think Junio is right about not wanting 47 different tiny auxiliary files for a single pack. We are unlikely to create that many, but right now there are proposals floating around for at least 2 new auxiliary files (commit cache and reachability bitmaps). So its not impossible that another will be discovered in the future.

Junio may be right about the hole in the index file for git-core. I haven't checked the JGit implementation, but I suspect it does not have this hole. IIRC JGit consumes the index sections and then expects the pack trailer SHA-1 to be present immediately after the last table. This happens because JGit doesn't use mmap() to load the index, it streams the file into memory and does some reformatting on the tables to make search faster.

If we are going to change the index to support extension sections and I have to modify JGit to grok this new format, it needs to be index v3 not index v2. If we are making index v3 we should just put index v3 on the end of the pack file.