Skip to content

Confirm the bare object stores are bounded #453

Description

@blooop

Question

Are the .bare object stores actually bounded, or is that an assumption?

Cheap to settle and worth settling, because if it is wrong it is a leak inside every clone tree the other tickets are reasoning about.

The reasoning that says fine: the sweep fetches git fetch origin +refs/heads/*:refs/heads/* --tags --prune into the bare, so refs deleted upstream are pruned and the ref count is bounded by the remote; git's own gc.auto is left at its default, so loose objects get packed without devlaunch doing anything. No production code runs gc or repack (only tests do), which is fine if auto-gc is really firing.

What to actually check, on a real machine with real history rather than by reasoning:

  1. Measure .bare sizes across the repos in a real cache, and git count-objects -v in the largest. Are loose objects accumulating, or is auto-gc keeping up?
  2. Does gc.auto fire in a bare repository under the fetch pattern used here, or is there a condition (bare, no reflog, fetch rather than commit) that stops it?
  3. +refs/heads/*:refs/heads/* fetches every branch as a local ref. On a repository with thousands of stale branches, what does that cost, and does --prune actually remove refs for branches deleted upstream?
  4. Since clone objects are hardlinked from the bare, confirm what that means for measurement: a du that double-counts them would misreport every other figure this map produces, and --ls --size is already in scope for attribution.

Record the numbers on the ticket. If it is bounded, this closes as confirmation and the map gains a line saying so, which is worth more than the assumption. If it is not, graduate a ticket.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions