From: Nguyen Thai Ngoc Duy Date: Sun, 30 Oct 2011 05:40:27 GMT Subject: Re: [RFC/PATCH] define the way new representation types are encoded in the pack Message-ID: In-Reply-To: <7vwrbptzjm.fsf@alter.siamese.dyndns.org> On Fri, Oct 28, 2011 at 1:12 PM, Junio C Hamano wrote: > 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. >  - 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