multi-pack-index expiration ineffective due to many pack-files keeping small object counts

[derrickstolee]

• [X] I was not able to find an open or closed issue matching what I'm seeing, including in the git-for-windows/git tracker.

When exploring my .scalarCache for the Office monorepo, I saw many prefetch pack-files that had not been deleted by routine maintenance. I ran and reran git maintenance run --task=incremental-repack expecting old pack-files to be deleted. However, the old pack-files are not being removed.

I added some trace2 statements to the expiration code and found that these pack-files still have a number of objects (sometimes as low as 2 or 3, but other times in the hundreds or thousands) reference by the multi-pack-index.

The root cause is likely a problem with the git multi-pack-index repack process instead of the expire operation. I may investigate this later, but need to make a note now before I forget.

• If the problem was occurring with a specific repository, can you specify the repository?

  • [X] Office monorepo

[derrickstolee]

This is new behavior in 2.45.0 and due to b7d6f23a17110d597d58f4a8e1b34b7a72c43fe1. I intend to revert this in microsoft/git before 2.46.0.vfs.0.0 but will investigate more deeply for an upstream fix.

[dscho]

@derrickstolee now that you fixed this in #678, shall we close this ticket? Or do you want to wait until there is an official release with the work-around?

[derrickstolee]

@dscho I have an internal ticket to track the upstreaming of this change, so we can close this. Thanks for your help!

[dscho]

Great, thank you for letting me know!