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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 24, 2020, 20:41 UTC
Message-ID: <xmqqd0a3pvjl.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20200224181204.GA2130083@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 12 quoted lines

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

Show 12 quoted lines

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