Re: [PATCH 1/2] t5332-multi-pack-reuse.sh: demonstrate duplicate packing failure

From: Taylor Blau <me@ttaylorr.com>
Date: Nov 14, 2024, 13:37 UTC
Message-ID: <ZzX9BgmxTgi6Pk8z@nand.local>
In-Reply-To: <xmqq8qtm8vps.fsf@gitster.g>

On Thu, Nov 14, 2024 at 10:12:15AM +0900, Junio C Hamano wrote:

Show 24 quoted lines

> Taylor Blau <me@ttaylorr.com> writes:
>
> > +test_expect_failure 'duplicate objects with verbatim reuse' '
> > +	git init duplicate-objects-verbatim &&
> > +	(
> > +		cd duplicate-objects-verbatim &&
> > +
> > +		git config pack.allowPackReuse multi &&
> > +
> > +		test_commit_bulk 64 &&
> > +
> > +		# take the first object from the main pack...
> > +		git show-index <$(ls $packdir/pack-*.idx) >obj.raw &&
> > +		sort -nk1 <obj.raw | head -n1 | cut -d" " -f2 >in &&
> > +
> > +		# ...and create a separate pack containing just that object
> > +		p="$(git pack-objects $packdir/pack <in)" &&
> > +		git show-index <$packdir/pack-$p.idx &&
>
> Is this done so that "git show-index" fails when the .idx file fed
> is malformed?  Or is it a leftover debugging aid, where a human
> developer was helped by eyeballing the contents of the .idx file in
> human readable form?  If the latter, do we perhaps want to "parse"
> the output the same way in this test to validate our expectation?

Oops. This is stray debugging left over that I forgot to take out before committing. That makes it the latter of the two you mentioned, but I don't think we need to validate the output of 'git show-index' in this instance.

We're just relying on pack-objects to generate a pack containing a single object, which feels like basic functionality not worth explicitly making an assertion on.

There is a subtle assertion on the line below here:

> > +		git multi-pack-index write --bitmap --preferred-pack=pack-$p.idx &&

that the pack (a) exists, and (b) has at least one object, since both conditions must be met for a pack to become preferred in a MIDX bitmap.

But beyond that, I don't think we need to validate the output of show-index here. I'll remove the stray debugging line and send a new round. Sorry about that, and thanks for spotting!

Thanks, Taylor