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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux