Currently, filesystem.ObjectStorage loads in all the index files at once during requireIndex, which will fail if the list of packs/indexes changed during loading. However, once the initial index loading succeeds, the list of indexes is persisted. If a packfile corresponding to one of the indexes is deleted, any operations interacting with it will fail (supposedly with dotgit.ErrPackfileNotFound, coming from DotGit.ObjectPack) until Reindex is called manually. The only case where a packfile deletion would not cause an error would be when that packfile has been loaded and cached (KeepDescriptors is true), but there's no option to force load all the packfiles along with the indexes.

In my opinion, this should be something that is handled by the Git library, not on a higher level. For example, gitoxide loads indexes lazily, and when it detects that an index/packfile is gone, it silently ignores the error, and later reloads the list of packfiles. I'm guessing libgit2 has some similar mechanism.

If the go-git team would consider this something that should be handled internally, I'd be happy to help with the implementation, since currently I'm forced to use my own ObjectStorage implementation instead. I see two possible solutions which can be implemented:

1. Add an option for requireIndex to force-load all the associated packfiles and cache them, implying KeepDescriptors. Since the file descriptors of the packfiles would be opened, they will continue to be available for access until closed one way or another.
2. Reindex automatically whenever ErrPackfileNotFound occurs. Additionally, re-validate index list when ErrObjectNotFound occurs, since a new object not present in the previous packs might be packed by the time it is needed, in which case go-git will currently silently fail.