From: Junio C Hamano Date: Mon, 24 Feb 2020 20:41:50 GMT Subject: Re: [PATCH v2 07/24] t6300: abstract away SHA-1-specific constants Message-ID: In-Reply-To: <20200224181204.GA2130083@coredump.intra.peff.net> Jeff King 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=" and at that point it would really become fuzzy what we are checking ;-)