Only the owner's git push through the remote helper starts a compaction (helper.rsafter_push). Every other write adds a pack and never compacts:
pushes through the gateway (knotless-servegateway.rs, both the push and the queued commit paths),
knotless commit and the MCP server's commit (commit.rs calls push::push directly),
forge writes such as retarget and fork copies (forge.rs).
A repository written only those ways, which is how agents and collaborators are meant to write, gains a pack with every write until its owner runs knotless compact by hand. Clones and fetches slow with every pack, and inline packs fill the owner's records.
Proposals, any of which would do:
Move the trigger from the helper into push::push (or a shared after-push step), so every owner-authenticated write checks the threshold. commit and MCP run as the owner already; the gateway pushes with the owner's session too. Background mode spawns knotless compact, which a server process may not want: serve could compact inline on its own task instead.
Let serve compact: it follows every repository's packs through Jetstream and holds the owner's gateway session, so it could compact a repository it sees cross the threshold.
Let the runner compact on a schedule for the repositories it serves.
Whichever it is, compaction needs the owner's credentials, and only one compactor should run per repository at a time (two would fold the same packs and one lose its applyWrites, harmlessly but wastefully).
Found by the storage.md audit; the page now says these writes never compact.
chadtmiller.com/knotless
Only the owner's
git pushthrough the remote helper starts a compaction (helper.rsafter_push). Every other write adds a pack and never compacts:knotless-servegateway.rs, both the push and the queued commit paths),knotless commitand the MCP server'scommit(commit.rscallspush::pushdirectly),forge.rs).A repository written only those ways, which is how agents and collaborators are meant to write, gains a pack with every write until its owner runs
knotless compactby hand. Clones and fetches slow with every pack, and inline packs fill the owner's records.Proposals, any of which would do:
push::push(or a shared after-push step), so every owner-authenticated write checks the threshold.commitand MCP run as the owner already; the gateway pushes with the owner's session too. Background mode spawnsknotless compact, which a server process may not want: serve could compact inline on its own task instead.Whichever it is, compaction needs the owner's credentials, and only one compactor should run per repository at a time (two would fold the same packs and one lose its
applyWrites, harmlessly but wastefully).Found by the storage.md audit; the page now says these writes never compact.