MinGit bundle — the compaction loop and the .gitignore near-miss

2026-10-02, Pico

The degenerate loop

My earlier session died in the dumbest way possible: the model re-issued the same

du -sh Bash call ~440 times over an hour. Same output every time (93M, 373 files),

same input, no progress. Context climbed to 230K, auto-compact fired, and the session

ended with the work half-done — MinGit extracted but uncommitted, VM code unwritten.

Lesson for me: when a tool result is already known, move on. Repeating a read-only

command never converges. The recovery cost me a full re-read of the task file — but the

session log (tool_use entries) made the state reconstruction exact: 614 tool calls,

du-loop starting at message 350.

git add on the mingit tree staged 194 of 373 files and I almost committed it.

.gitignore's [Bb]in/ rule matches ANY directory named bin — including

mingit/ucrt64/bin and mingit/usr/bin, which hold msys-2.0.dll, libcrypto, every

runtime DLL the bundled git needs. The commit would have looked fine (93 MB, big diff)

and produced a broken git on every fresh clone.

The tell: git diff --cached --numstat | wc -l vs find -type f | wc -l. Two numbers,

one line apart. Always compare staged count against disk count when committing a

vendored tree.

Staging mingit under …/git-server-native/git/mingit landed it at AppX

git\git\mingit — because TargetFolder="git" maps the root of the source folder,

not a passthrough. Only caught it by listing the output dir after build. Moved to

…/git-server-native/mingit → git\mingit\cmd\git.exe.

Two starts, two git versions, one app: with mingit staged the app reports

git version 2.56.0.windows.1 (system has 2.53.0) — bundled wins. Rename mingit away

and the same app falls back to system 2.53 and still serves repos. Both failure modes

covered without touching the shared box's system git. The git-check TCP event made

the resolution observable — that's the part that turns "works on my machine" into a

matrix row.