OpenClaw merged a Git maintenance repair this morning for managed worktrees whose multi-pack index points at a pack file that has already been replaced.
The fix landed in PR #165995, "fix(git): rebuild stale worktree pack indexes." It is labeled P2, but its impact is practical: stale index state could suspend repository maintenance and make Git-backed session statistics and cleanup more expensive.
What Broke
Git multi-pack indexes are designed to speed up object lookup across pack files. The edge case here is stale inventory. If an old multi-pack index names a pack that no longer exists, Git can fail before it gets far enough to discover the current pack files.
The PR describes the failing symptom as could not load pack. In OpenClaw's managed worktree maintenance path, that meant repair could fail at exactly the moment it needed to recover.
This is the kind of infrastructure bug that rarely looks dramatic in the UI but can quietly tax everything built on top of the worktree: statistics refreshes, cleanup, maintenance, and removal.
The Repair
OpenClaw now builds the multi-pack index from the current shallow directory inventory instead of letting Git implicitly reuse the stale index.
The important detail is that the fix still uses Git's native atomic writer. It streams the current pack index filenames to multi-pack-index write --stdin-packs, preserving Git's publication behavior and OpenClaw's existing maintenance and removal ownership. The PR explicitly says OpenClaw does not delete or rename the live multi-pack index or modify packs.
That narrowness matters. Rebuilding indexes in a managed worktree system is not a place to get clever. The safer move is to give Git the right current inventory and let Git perform the publication.
User Impact
For users, the expected outcome is less stuck maintenance and less expensive Git-backed session state when old pack references are left behind.
The PR says managed-worktree maintenance and removal can rebuild the stale index while preserving repository objects. It also preserves the existing revision cache for PR statistics and the five-minute refresh behavior for unstaged and untracked edits.
No config or schema changes are involved.
Evidence From the PR
The author reproduced the defect in a real repository by restoring an old multi-pack index after repacking. The original repair failed with exit 255 and the could not load pack error. The candidate rebuild was then checked with multi-pack-index verify and a HEAD content read.
The PR also includes a synthetic pack-lookup rig with 50 worktrees, 10 polls, 1,000 tracked files, 1,901 reachable-blob promisor packs, one metadata pack, and two concurrent Git children. In that rig, the old repair failed and the rebuilt multi-pack index verified successfully. All reads reported identical statistics before and after.
The measured child-time reduction was 23.8 percent in that synthetic setup. The PR is careful not to overclaim that number as a production-wide speedup; it frames the deterministic repair failure as the reason to ship.
Bottom Line
This is a maintenance-path fix with a good engineering shape: preserve ownership, preserve Git's atomic publication, and rebuild from facts that exist now instead of trusting a stale index. For OpenClaw operators using managed worktrees heavily, that should mean fewer expensive or suspended Git maintenance paths after pack replacement.