On Fri, Aug 28, 2020 at 04:31:25AM -0400, Jeff King wrote: > On Fri, Aug 28, 2020 at 02:26:19AM -0400, Jeff King wrote: > > > On Thu, Aug 27, 2020 at 08:39:40PM -0400, Taylor Blau wrote: > > > > If I'm understanding midx_contains_pack() correctly, then the code > > looking for ".pack" could never have matched, and we would never have > > deleted a midx here. Which makes me wonder why the "repack removes > > multi-pack-index when deleting packs" test ever succeeded. > > Sorry, this is all nonsense. > > I forgot about the hackery added in 013fd7ada3 (midx: check both pack > and index names for containment, 2019-04-05). And anyway, the patch > above is totally bogus because we need the ".pack" form in the buffer > when we call unlink_pack_path(). Yeah, 013fd7ada3 is definitely a hack, but what you have is definitely incorrect. > So there's definitely something more odd going on in that failing test. It's the funky order that we load the MIDX chain in (which is that the MIDX belonging to the deepest alternate shows up *first* as 'r->objects->multi_pack_index', and that the local MIDX shows up as the last thing when traversing '->next'). I sent what I consider to be a little bit of a hack in [1], but it's definitely enough to fix t7700.6. > -Peff Thanks for reporting it. Taylor [1]: https://lore.kernel.org/git/20200828180621.GA9036@xxxxxxxxx.local/T/#u
