fix(git): cap and stream untracked-file line counting

[pauldambra]

Fixes an OOM in the main process that freezes the app a few seconds after the sidebar paints, on accounts whose selected directory is a monorepo with large untracked files (lockfiles, build artifacts, source maps). countFileLines was reading each file's full contents into V8 memory via fs.readFile, run 16-way concurrent against tens of thousands of paths — a single big file in any of the 16 in-flight reads could push the heap past 4 GB and crash main. Now we stream-count \n bytes with createReadStream, so peak per-stream memory is ~64 KB regardless of file size and the 16-way batch stays bounded around 1 MB total.

Problem

• countFileLines in packages/git/src/queries.ts was reading each untracked file fully into memory via fs.readFile(filePath, "utf-8"), and the caller (getChangedFilesDetailed) runs it 16-way concurrent against up to 50k untracked paths from streamGitStatus.
• On a monorepo with multi-MB build artifacts, lockfiles, or other large untracked files, peak heap was 16 × file_bytes × 2 (V8's UTF-16 cost). That blew past Electron's 4 GB main-process heap on real-world repos and OOM'd the main process. The renderer appeared frozen ~2–3 s after the sidebar painted because all its in-flight tRPC calls were waiting on a dead main. Symptom in chromium.log was a silent OOM error in V8: Scavenger: semi-space copy Allocation failed, with no [ipc-rate] warning before it (no IPC storm — just main quietly running out of heap).
• Regression introduced by feat: virtualized and optimized diff rendering #2113 (c617988), which removed the previous 10k-file cap and switched to concurrent reads when migrating to streamGitStatus. Bisected on a freshly-onboarded data dir pointed at this monorepo.

Fix

• Stream the file with createReadStream (64 KB highWaterMark) and count \n bytes byte-by-byte. Per-stream memory stays at ~64 KB regardless of file size, so peak across 16 concurrent reads is ~1 MB total — well under any heap pressure threshold.
• Preserves the original return semantics: trailing-newline-aware count, 0 for empty / non-regular files / errors.
• No artificial file-size cap — every untracked file gets an accurate line count. (An earlier version of this PR gated at 1 MB, which silently returned linesAdded: 0 for any larger file. That's a correctness regression and the streaming alone is already enough to fix the OOM, so the cap was dropped in the follow-up commit.)

Test plan

• pnpm --filter @posthog/git test src/queries.test.ts — new getChangedFilesDetailed tests pass (small-file accuracy + correct counting of a multi-MB untracked file that previously OOM'd)
• pnpm --filter code typecheck
• pnpm dev against a fresh data dir pointed at this monorepo — previously OOM'd within ~3 s of MainSidebar paint, now stays responsive
• CI

🤖 Generated with Claude Code

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/git/src/queries.test.ts:257-268
**Prefer parameterised tests for the two line-count cases**

The team's convention is to always use parameterised tests. The two sub-cases here — file with a trailing newline and file without one — test the same behaviour (accurate line counting) with different inputs and expected values, which is exactly the pattern parameterisation is designed for. A `it.each` table would express the intent more clearly and make it trivial to add further edge-cases (e.g. an empty file, a CRLF file) without repeating the repo-setup boilerplate.

_{Reviews (1): Last reviewed commit: "fix(git): cap and stream untracked-file ..." | Re-trigger Greptile}

[pauldambra]

Note

🤖 Automated comment by QA Swarm — not written by a human

Multi-perspective review by qa-team (reliability / performance / data-integrity / compatibility / two generalists), paul-reviewer, and xp-reviewer. All three reviewers converged on the same two MEDIUM findings, posted inline. Six lower-severity findings (Buffer.indexOf perf, dead string-chunk branch, symlink-follow risk, extra fs.stat, lastByte dead branch, edge-case test coverage, magic-number extraction) were noted but are being addressed silently in the next commit.

Verdict: 💬 APPROVE WITH NITS — no blocking findings.