Skip to content

Always remove bitmaps when linking a repo

Patrick Steinhardt requested to merge pks-objectpool-member-bitmaps into master

When a repository has multiple bitmaps for its packfiles, Git will generate a warning message that is visible to the user. While it is hard to end up with multiple bitmaps, our object pool mechanism links together multiple repositories via alternates, which may also trigger this warning in case both pool and the linked repo have a bitmap. This is why we proactively remove bitmaps for a repo that we're linking to an object pool.

Except that we don't in some cases: upon linking the repo to its pool, we call removeMemberBitmaps(). This function will only remove bitmaps of the repository if its target pool already has at least one bitmap. This is likely the case for object pools which existed for a prolonged time already and have thus generated one via any of the housekeeping mechanisms. But for a newly created object pool, which is cloned via git clone --bare --local, there won't be any and as a result, we won't remove any potentially existing bitmaps for the repo we're linking.

In the beginning, this will not generate a warning. But if the linked repo is not getting pushed to and thus keeps its bitmap and meanwhile the object pool gets pushed to via another linked repo, then we will eventually generate a bitmap for the object pool and warnings will start to pop up when fetching from the repo.

To fix this, let's simply always remove bitmaps for a repo we're adding to an object pool.


This is related to #1728 (closed). I've sifted through Gitaly's and Git's code base most of the day to check whether there's any other cases where we could accidentally generate bitmaps in the linked repo, but I didn't find any. I'm thus optimistic that this actually solves the issue, which would mean that we do not have to employ any filtering of the warning at all.

Edited by Zeger-Jan van de Weg

Merge request reports