Re: [RFC/PATCH] define the way new representation types are encoded in the pack
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 30, 2011, 07:11 UTC
- Message-ID
- <7v4nyrrm1w.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CACsJy8Cz0R_s+VYRd+1wTTfbt_vH5dd3ALgZip0xn7rfYf6gpw@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
Show 5 quoted lines
> 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.
I have no problem with that (I am not worried about minor details of the actual implementation of cat-tree yet).
> 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?
In pack? Loose? Both?
What kind of payload and use case do you have in mind?