Re: [PATCH v2 07/24] t6300: abstract away SHA-1-specific constants

Jeff King [off-list ref] writes:

On Mon, Feb 24, 2020 at 10:01:08AM -0800, Junio C Hamano wrote:

quoted

quoted

-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.

quoted

quoted

+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 ;-)