Re: [PATCH v2] Add an option to git-ls-tree to display also the size of blob

["Shawn O. Pearce" <spearce@spearce.org>]

Jakub Narebski <jnareb@gmail.com> 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.