Git Packfile Inspector (.pack / .idx)

Because it is the size of the delta, not of the object the delta rebuilds. A deltified object stores only the instructions to turn some other object into this one — copy this range from the base, insert these literal bytes — and the size in its header describes that instruction stream. git verify-pack -v prints exactly the same number, for exactly the same reason. The size of the reconstructed object is written inside the compressed delta data, so it cannot be reported without decompressing, which this page deliberately never does.

Both store a delta; they differ in how they point at the base. An ofs-delta gives a backwards distance in bytes from its own offset, which is compact and self-contained; a ref-delta gives the base's full object id, which costs 20 or 32 bytes and requires a lookup. Git has written ofs-deltas by default since 1.5, and only falls back to ref-deltas when told to — repack.useDeltaBaseOffset set to false, for the benefit of very old clients — or when the base is not in this pack at all, which is what happens in the "thin" packs sent over the wire during a fetch.

It is a trade. Chain length is how many deltas have to be applied, one after another, before an object exists again, so a depth of 50 means reading that one object touches 51 objects. Deep chains pack smaller and read slower, and git bounds them: repack takes --depth, whose default is 50. If a pack shows most of its objects at depth zero, delta compression barely helped — usually because the content is already compressed, like images, archives or encrypted blobs.

Not by name. A pack stores objects, not paths: a blob is anonymous, and the file names live inside tree objects, which are themselves compressed. What this page gives you is the id of the biggest object, and from there git rev-list --objects --all | grep <id> in the repository names the path, or git cat-file -p <id> shows the content. The reverse direction — id to size to path — is exactly the workflow behind most "why is my clone 2 GB" investigations.

Not without decompressing. Objects sit back to back with no length field for the compressed data: the only way to find where one ends is to inflate it until the zlib stream terminates. The .idx already knows every offset, so with it the size in the pack is the distance to the next offset and no decompression is needed anywhere. Given a pack with no index at all, git itself rebuilds one with git index-pack, and that command does inflate every object.

The last two hashes of an index are the checksum of the pack it describes and then the index's own checksum, so a mismatch means the two files were not written together. Usually they were copied from different places or one was regenerated; the offsets in the index then point into the wrong bytes and every type and size after that is nonsense. The fix is not to trust the pair: fetch the pack again, or rebuild the index from the pack with git index-pack.