On Wed, Sep 27, 2023 at 11:47 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Just wondering if it would help to have the third kind of object > representation in the object database, sitting next to loose objects > and packed objects, say .git/objects/verbatim/<hex-object-name> for > the contents and .git/objects/verbatim/<hex-object-name>.type that > records "blob", "tree", "commit", or "tag" (in practice, I would > expect huge "blob" objects would be the only ones that use this > mechanism). Yeah, I think it could help handle large blobs. I guess it would rely on the underlying filesystem to store the object size. > The contents will be stored verbatim without compression and without > any object header (i.e., the usual "<type> <length>\0") and the file > could be "ln"ed (or "cow"ed if the underlying filesystem allows it) > to materialize it in the working tree if needed. > > "fsck" needs to be told about how to verify them. Create the object > header in-core and hash that, followed by the contents of that file, > and make sure the result matches the <hex-object-name> part of the > filename, or something like that. What happens when they are transferred? Should the remote unpack them into the same kind of verbatim object?
