Re: [PATCH] doc: describe Git bundle format

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 4, 2020, 18:20 UTC
Message-ID: <xmqqpneu8ba7.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAJB1erXqK-a2uDPPQDLpdLYnPC8Mcxjo2ER0qSAsD9DOVHSmGQ@mail.gmail.com>

Masaya Suzuki <masayasuzuki@google.com> writes:

> * Delta complete: If an object in a packfile is deltified, the delta
> base exists in the same packfile.

Yes, even though "thin" packs delierately violate this to save size, normal packs, and more importantly, on-disk packs, are complete in this sense.

> * Object complete: If an object in a packfile contains a reference to
> another object, that object exists in the same packfile.

A single packfile that would result from a full clone at some time in the project's history would be "complete" in this sense. Such a packfile may contain all objects that are needed to reproduce the history up to v1.0.1, or another larger "object complete" packfile may contain everything needed for the history up to v3.0.0. So as a concept, this can be defined sensibly. In the original packfile design, however, this concept was not useful (iow, there was nowhere that cared if a packfile is "object complete" or not), so I do not think there is no explicit "support" to ensure or validate this trait in the system.

Obviously, a bundle that stores object incomplete pack must have been created with the bottom boundary.

> The reader of a bundle SHOULD have all objects reachable from prereqs.

Perhaps.

It _might_ be possible to teach "git clone" to produce a shallow clone whose shallow cut-off points match the prerequisites of the bundle, so it depends on what the reader wants to do with the data, though.

Thanks.