Fleet scans still count stale local checkouts as findings; reporting behind-ness needs a fetch to be honest #24

New Issue

2026-08-13T23:06:19+03:00

issuer-agent commented

2026-08-13 23:06:19 +03:00

Deferred from oleks/pipetree#21 (closed by commit f12d39a, which excluded trees that are in no git repository at all). Measured effect: a WP001 sweep of ~/projects went from 13 hits to 4. The six removed were unpacked plugin installations (derived trees, regenerated on install).

What remains: the four surviving hits are

forrest/.woodpecker/check.yaml — deliberate, and now suppressible via the # pipetree:ignore WP001 -- <reason> directive shipped in oleks/pipetree#20 (not yet applied there; the user chose to leave forrest untouched for now).
heatwave-backend/.woodpecker/test.yaml and oracle-adb-backend/.woodpecker/test.yaml — STALE LOCAL CHECKOUTS, already fixed at origin/main; the local working trees are behind.
scratch/claude-plugin-cluster/.woodpecker.yaml — a stale SECOND clone whose canonical checkout is already fixed.

So three of the four remaining are the "stale checkout" class that oleks/pipetree#21 also floated addressing ("report per-finding whether the checkout is behind its remote so a reader can discount stale hits").

Why it was deliberately NOT implemented, and what the real difficulty is (preserve this argument):

Comparing local HEAD to its remote-tracking ref (refs/remotes/origin/<branch>) using only on-disk data cannot support the claim honestly. A checkout that has never fetched has a stale remote-tracking ref, so it would report "in sync" while being months behind. That is FALSE REASSURANCE on a tool people gate pushes on — strictly worse than the noise it removes, and the same misfire dynamic recorded in oleks/emmett#317. pipetree's constitution (principle IV) also forbids guessing where the underlying fact is unverified: it must mark unknown rather than assert.

Doing it properly requires a network fetch, which is a genuinely different trade-off:

speed (the constitution requires anything in a pre-push hook to stay fast),
offline behaviour (must degrade to a visible skip, never hang or fail the push),
read-only discipline (a fetch writes to the local object store — it does not mutate the SUBJECT repo, but it is no longer a pure filesystem read, which is pipetree's default posture).

Suggested shape to consider (not prescribed): an opt-in flag (e.g. -freshness) that, when passed, reports per-project whether the checkout is behind/ahead/diverged/unknown, with unknown as the honest default whenever the remote-tracking ref's age cannot be established — plus a visible skip when offline. It should never change exit codes, since staleness is a fact about the checkout, not a defect in the config.

Links: oleks/pipetree#21 (closed, the derived-tree half), oleks/pipetree#20 (suppression, covers the forrest case), oleks/emmett#317.

**Deferred from** oleks/pipetree#21 (closed by commit `f12d39a`, which excluded trees that are in no git repository at all). Measured effect: a WP001 sweep of ~/projects went from 13 hits to 4. The six removed were unpacked plugin installations (derived trees, regenerated on install). **What remains**: the four surviving hits are - `forrest/.woodpecker/check.yaml` — deliberate, and now suppressible via the `# pipetree:ignore WP001 -- <reason>` directive shipped in oleks/pipetree#20 (not yet applied there; the user chose to leave forrest untouched for now). - `heatwave-backend/.woodpecker/test.yaml` and `oracle-adb-backend/.woodpecker/test.yaml` — STALE LOCAL CHECKOUTS, already fixed at `origin/main`; the local working trees are behind. - `scratch/claude-plugin-cluster/.woodpecker.yaml` — a stale SECOND clone whose canonical checkout is already fixed. So three of the four remaining are the "stale checkout" class that oleks/pipetree#21 also floated addressing ("report per-finding whether the checkout is behind its remote so a reader can discount stale hits"). **Why it was deliberately NOT implemented, and what the real difficulty is** (preserve this argument): Comparing local HEAD to its remote-tracking ref (`refs/remotes/origin/<branch>`) using only on-disk data cannot support the claim honestly. A checkout that has never fetched has a stale remote-tracking ref, so it would report "in sync" while being months behind. That is FALSE REASSURANCE on a tool people gate pushes on — strictly worse than the noise it removes, and the same misfire dynamic recorded in oleks/emmett#317. pipetree's constitution (principle IV) also forbids guessing where the underlying fact is unverified: it must mark unknown rather than assert. Doing it properly requires a network fetch, which is a genuinely different trade-off: - speed (the constitution requires anything in a pre-push hook to stay fast), - offline behaviour (must degrade to a visible skip, never hang or fail the push), - read-only discipline (a fetch writes to the local object store — it does not mutate the SUBJECT repo, but it is no longer a pure filesystem read, which is pipetree's default posture). **Suggested shape to consider** (not prescribed): an opt-in flag (e.g. `-freshness`) that, when passed, reports per-project whether the checkout is behind/ahead/diverged/unknown, with `unknown` as the honest default whenever the remote-tracking ref's age cannot be established — plus a visible skip when offline. It should never change exit codes, since staleness is a fact about the checkout, not a defect in the config. **Links**: oleks/pipetree#21 (closed, the derived-tree half), oleks/pipetree#20 (suppression, covers the forrest case), oleks/emmett#317.

issuer-agent added the enhancement label 2026-08-13 23:06:19 +03:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: oleks/pipetree#24