Context
#43 fixed the specific failure mode from #42 (missing git identity silently breaking git commit/git worktree add in test fixtures, cascading into assertions that looked like real bugs in hooks/_lib.sh). It also added loud bad "fixture setup failed: ..." guards to the 3 git worktree-specific fixture chains, since those were directly implicated.
Two independent PR review agents (code-reviewer, silent-failure-hunter) both flagged that the same structural pattern remains on ~18 other fixture blocks that only do git init && git commit (no worktree):
grep -n "git init -q && git commit" tests/run.sh
Each is still ( ... ) 2>/dev/null with no exit-status check. Any other setup failure in that chain (git binary broken/missing in a stripped image, commit.gpgsign set globally and no key configured, disk-full mktemp, an incompatible git version rejecting a flag used downstream) would again surface as a bogus assertion failure against _lib.sh's logic rather than "the fixture didn't build" — the exact debugging trap #42/#43 exist to close, just not fully closed.
Proposal
A shared fixture_repo() helper (or similar) that runs git init && git commit [&& ...], checks $?, and on failure calls bad "fixture setup failed: <label>" with a clear message — replacing the ~18 duplicated ( ... ) 2>/dev/null blocks with one hardened call site.
Priority
Low/nice-to-have — no evidence of an active recurrence on this pattern (only the worktree-specific chains have actually bitten anyone, twice now). Worth doing opportunistically or if it bites again.
Related
Follow-up from #42 / #43 review.
Context
#43 fixed the specific failure mode from #42 (missing git identity silently breaking
git commit/git worktree addin test fixtures, cascading into assertions that looked like real bugs inhooks/_lib.sh). It also added loudbad "fixture setup failed: ..."guards to the 3git worktree-specific fixture chains, since those were directly implicated.Two independent PR review agents (code-reviewer, silent-failure-hunter) both flagged that the same structural pattern remains on ~18 other fixture blocks that only do
git init && git commit(no worktree):Each is still
( ... ) 2>/dev/nullwith no exit-status check. Any other setup failure in that chain (git binary broken/missing in a stripped image,commit.gpgsignset globally and no key configured, disk-fullmktemp, an incompatible git version rejecting a flag used downstream) would again surface as a bogus assertion failure against_lib.sh's logic rather than "the fixture didn't build" — the exact debugging trap #42/#43 exist to close, just not fully closed.Proposal
A shared
fixture_repo()helper (or similar) that runsgit init && git commit [&& ...], checks$?, and on failure callsbad "fixture setup failed: <label>"with a clear message — replacing the ~18 duplicated( ... ) 2>/dev/nullblocks with one hardened call site.Priority
Low/nice-to-have — no evidence of an active recurrence on this pattern (only the worktree-specific chains have actually bitten anyone, twice now). Worth doing opportunistically or if it bites again.
Related
Follow-up from #42 / #43 review.