Jakub Narebski <jnareb@xxxxxxxxx> wrote: > Rationale: for non-blob entries size of an object has no much > meaning, and is not very interesting. Moreover, in planned > pack v4 tree objects would be constructed on demand, so tree > size would need to be calculated... although isn't object size > stored in the header? Yes and no. In pack v4 the object sizes stored within the packfile are more about what we need to know in order to efficiently unpack the object than about supplying the canonical format length. If a value is redundant, we don't store it. The canonical format length is almost always redundant. For blobs we still need the raw data length to unpack efficiently, and hence we have the blob's canonical size readily available. For trees its actually more the tree entry record count, as that is all we need to know in order to recover the tree. For commits we don't even need a length, but we instead have the number of parent commits. Since pack v4 is really about faster runtime decoding our ability to reproduce canonical encoding of objects is reduced slightly. I think that's OK as we actually only need the canonical encoding infrequently (index-pack during network transfer, cat-file) and we're not really considering pack v4 for network transfer. Yet. > I hope this addresses concerns mentioned in this thread: the > alternate name --size for -l/--long option, and showing size > for tree (and commit/submodule) objects. Yes, thanks! -- Shawn. - 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
