Re: [RFC/PATCH] define the way new representation types are encoded in the pack

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Oct 30, 2011, 05:40 UTC
Message-ID: <CACsJy8Cz0R_s+VYRd+1wTTfbt_vH5dd3ALgZip0xn7rfYf6gpw@mail.gmail.com>
In-Reply-To: <7vwrbptzjm.fsf@alter.siamese.dyndns.org>

On Fri, Oct 28, 2011 at 1:12 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> As people may be able to guess from the name, CAT_TREE is envisioned to
> encode a large data (primarily of type "blob") by recording the object
> name of a tree object and probably the total length, and would represent
> the concatenation of all blobs contained in the tree object when the tree
> is traversed in some fixed order (e.g. Avery's "bup split"). I am guessing
> that the payload for CAT_TREE representation type will be:
>
>  - 20-byte object name for the top-level tree object;

Because all blobs in this tree object must be in a fixed order, and they won't likely have meaningful names nor permission, should CAT_TREE payload is a SHA-1 sequence of all blobs (or cat-trees if we want nested trees) instead? IOW the tree is integrated into cat-tree object, not as a separate tree object.

Show 9 quoted lines

>  - type of the basic object (commit, tree, blob, or tag) it represents,
>   even though it is unlikely that we would want to record such a large
>   commit or tag that needs CAT_TREE representation;
>
>  - the total length of the basic object it represents, even though it is
>   redundant (you could traverse and sum the sizes of blobs contained in
>   the tree object), it would help sha1_object_info() and friends. This
>   will be the "some size" I mentioned in the previous message for this
>   representation type.

Not sure if it's related to representation types, but is there any way (perhaps FLAT_BLOB type?) we can mark an object uncompressed, so we can mmap() and access it directly?

-- 
Duy