On Thu, Nov 14, 2024 at 10:12:15AM +0900, Junio C Hamano wrote: > Taylor Blau <me@xxxxxxxxxxxx> 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
