docs: row 118 brief, the host's git runs no background maintenance in a role clone (#1612)
Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
@@ -0,0 +1,60 @@
|
|||||||
|
# The host's git runs no background maintenance in a role clone (2026-10-14)
|
||||||
|
|
||||||
|
Filed by Sage from Dewey's row 117 review note (comment 28443), Gitea #1612, with Mos's
|
||||||
|
agreement in their reply to sage-0190. Low priority.
|
||||||
|
|
||||||
|
## No auto-maintenance from the host's git in a role clone
|
||||||
|
|
||||||
|
### Problem
|
||||||
|
|
||||||
|
The host runs git in each role clone at a launch
|
||||||
|
(`packages/seat/src/checkout.mjs`, `update()`). On git 2.55 a `fetch` can
|
||||||
|
start a detached `git maintenance run --auto` (or `gc --auto`) in that
|
||||||
|
clone. It keeps running after the host's call returns, in a clone the
|
||||||
|
session can write. It moves no ref value, index or tree, and the clean path
|
||||||
|
has done this since checkouts began. Row 117 made it happen at more
|
||||||
|
launches, since a clone on another branch or dirty now fetches too.
|
||||||
|
|
||||||
|
The host should run only the git it asks for. A background process that
|
||||||
|
outlives the call isn't covered by `GIT_LIMITS` and isn't in the launch
|
||||||
|
record.
|
||||||
|
|
||||||
|
### Owner and reviewer
|
||||||
|
|
||||||
|
- Owner: darkwing, after row 116.
|
||||||
|
- Reviewer: dewey (decision 130: the host runs git in a clone the session
|
||||||
|
can write).
|
||||||
|
|
||||||
|
### Files owned
|
||||||
|
|
||||||
|
- `packages/seat/src/checkout.mjs`, `SAFE` only
|
||||||
|
- `packages/seat/tests/checkout.test.mjs`
|
||||||
|
- `packages/seat/README.md`, where it lists the git config the host forces
|
||||||
|
|
||||||
|
### What ships
|
||||||
|
|
||||||
|
1. `SAFE` adds `-c maintenance.auto=false` and `-c gc.auto=0`. If you find
|
||||||
|
that git 2.55 needs another key to stop fetch's auto-maintenance, add it
|
||||||
|
and say why in the packet.
|
||||||
|
2. The README's list of forced config names the new keys and the reason.
|
||||||
|
|
||||||
|
### Not in this row
|
||||||
|
|
||||||
|
- Any other change to `SAFE`, `unsafe()`, `allowed()` or `gitEnv()`.
|
||||||
|
- Running maintenance in a clone on purpose.
|
||||||
|
|
||||||
|
### Acceptance
|
||||||
|
|
||||||
|
- A test pins that every git call the host makes in a clone carries both
|
||||||
|
keys. The rigged-clone test and the row 117 tests still pass unchanged.
|
||||||
|
- A test with a clone set to trigger auto-maintenance (for example
|
||||||
|
`gc.auto=1` and loose objects, or `maintenance.auto=true`) shows no
|
||||||
|
maintenance or gc process started after the launch's fetch. If git gives
|
||||||
|
no reliable way to observe that, say so in the packet and pin the
|
||||||
|
arguments instead.
|
||||||
|
- Mutants, listed in the packet: drop each key. Each one fails a test.
|
||||||
|
- Targeted builder gate (decision 136): seat, its importers and every
|
||||||
|
`scripts/test-*.sh` that reads a changed path. Dewey approves on the
|
||||||
|
issue naming the candidate manifest. Sage reruns the full gate at the
|
||||||
|
landing target. It goes live only through a re-pin on Mos's go
|
||||||
|
(decision 109).
|
||||||
Reference in New Issue
Block a user