An independent live review of the tidy found it could lose data: a merge
under pack.packSizeLimit published only the first of several output packs
(45 of 60 commits gone), erasing "commit-free" on-demand packs dropped trees
and blobs a local branch still needed once upstream had pruned them, a
process killed mid-erase left a multi-pack-index naming a deleted pack, and
a classification timeout was cached as "holds commits" forever.
The erase rule is now proof against local packs alone: a promisor pack goes
only when every object in it is also in another promisor pack (checked by
binary search over the .idx files, no git process per pack). Nothing stored
locally can be lost and nothing depends on the remote still serving it, so
the marker heuristics and commit classification are gone. Merges run with
pack.packSizeLimit=0 and refuse anything but exactly one output; the
multi-pack-index is dropped before any pack is removed, so a kill at any
point leaves git reading; a lock file keeps two tidies from each erasing a
pack because the other still holds its copies.
.keep files written by a fetch-pack/index-pack that died (older than an
hour) no longer pin their packs. git's own repack never touches .keep'd
packs, and on a real dev checkout 53 of them held 4.5 GB of duplicated
history downloads.
2fa8090568