On Thu, Mar 22, 2018 at 9:07 AM, Jeff King <p...@peff.net> wrote: > On Wed, Mar 21, 2018 at 05:31:14PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> > [...]Yes, having that many packs is insane, but that's going to be >> > small consolation to somebody whose automated maintenance program now >> > craps out at 16k packs, when it previously would have just worked to >> > fix the situation[...] >> >> That's going to be super rare (and probably nonexisting) edge case, but >> (untested) I wonder if something like this on top would alleviate your >> concerns, i.e. instead of dying we just take the first N packs up to our >> limit: > > I wish you were right about the rarity, but it's unfortunately something > I have seen multiple times in the wild (and why I spent time optimizing > the many-packs case for pack-objects). Unfortunately I don't know how > often it actually comes up, because in theory running "git repack" > cleans it up without further ado. But after these patches, not so much.
It's good to know this case is real and I can start to fix it (assuming that the other concern about readability will not stop this series). I think I'll try to fix this without involving repack. pack-objects can produce multiple packs, so if we have more than 16k pack files, we produce one new pack per 16k old ones. -- Duy
