Repository navigation
Let git pack-refs through the primary integration ref guard - #108
Merged
Merged
Conversation
git gc --auto runs pack-refs after ordinary commits, including in lane worktrees. Packing writes the integration ref into packed-refs as `0 -> current` and then prunes the loose copy as `current -> 0`, and the reference-transaction guard refused both as an unauthorized move, so repository maintenance never completed. A line now passes when the ref still resolves to the same commit afterwards. Real moves and deletes stay refused: deleting a packed ref always carries a `0 -> 0` line for the packed store.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
git gc --autoruns after ordinary commits, lane worktrees included, and itspack-refsstep was refused by the reference-transaction guard:The commit itself lands, but maintenance never finishes, so loose refs and objects pile up.
Packing moves a loose ref in two transactions:
0 -> currentintopacked-refs, thencurrent -> 0to prune the loose copy. The guard read both as a move of the integration branch.A line now passes when the ref still resolves to the same commit afterwards:
packed-refsReal moves and deletes of the integration ref are still refused. Deleting a packed ref always carries a
0 -> 0line for the packed store, and a loose-only ref has no packed value to fall back to, so neither qualifies. A degraded guard lets packing through for every branch the same way.The check runs before the ref-move authorization, so an authorized Syncwheel command's own
gc --autodoesn't spend its single-use authorization on a no-op.Tests cover
pack-refsfrom the primary and from a linked worktree, armed and degraded, and check that every move and delete form still gets refused on the packed ref. Without the fix they fail with the exact error above.Bumps to 0.45.1. Full suite: 990 tests OK.