On Fri, Oct 28, 2011 at 1:12 PM, Junio C Hamano <gitster@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html