Jeff King <peff@xxxxxxxx> writes: > On Mon, Feb 24, 2020 at 10:01:08AM -0800, Junio C Hamano wrote: > >> > -test_atom head objectsize 171 >> > -test_atom head objectsize:disk 138 >> > -test_atom head deltabase 0000000000000000000000000000000000000000 >> > +test_atom head objectsize $((131 + hexlen)) >> >> 171 == 131 + 40 and that is because we are looking at the initial >> commit, whose contents has a single object name (i.e. its tree). > > I wonder if it would be more readable to just pipe "cat-file" through > "wc -c", rather than hard-coding. Then there's no magic number at all. After seeing nearby tests use output from $(git rev-parse) as the expected output, I had a similar thought. >> > +test_atom head objectsize:disk $disklen > > Likewise for $disklen, if it's a loose object we could just get the > information from the filesystem. That would stop us caring about the > hash, _and_ it would make us robust to random changes in the zlib > compression. > > I'm not sure if we also check packed objects. If so, you can compute the > size from the output of show-index, which gives the offsets of each > object. That's also how Git does it internally, though, so I'm not sure > if that is getting too close to just testing nothing (but IMHO the thing > we're really covering here is the format routines). Somebody may find it tempting to use "cat-file --batch-check=<format>" and at that point it would really become fuzzy what we are checking ;-)