git calls in the tree/file-browser crash with ENOBUFS on large repos

What happens

Open diffity tree (or any tour view) on a large repo and the whole UI goes down with:

Something went wrong
Failed to get tree: Error: spawnSync git ENOBUFS

/api/tree returns a 500. Since the SPA surfaces that at the top level, views that don't even need the file tree (a code tour) go down with it too.

What I found

The git calls behind the file browser run through execFileSync("git", [...], { encoding: "utf-8" }) with no maxBuffer, so they get Node's 1 MB default. Once git ls-files prints more than 1 MB of paths, the call throws ENOBUFS. In 0.9.5's dist/index.js it's the git ls-files calls in getTreeEntries and getTreeFingerprint, the git status --porcelain -u, and the git rev-parse --show-toplevel calls.

How to reproduce

Any repo whose tracked paths exceed ~1 MB of text. Mine is a monorepo that vendors a few external repos as git subtrees, so git ls-files is ~14,300 files / 1.24 MB, just over the line. A large public repo would do the same.

git ls-files | wc -c   # > 1048576 reproduces it

Environment

• diffity 0.9.5
• node (system), macOS arm64

Start in dist/index.js at the git calls used by getTreeEntries, getTreeFingerprint, git status --porcelain -u, and git rev-parse --show-toplevel. Reproduce with a repository whose tracked paths exceed 1 MB using git ls-files | wc -c, then exercise diffity tree or /api/tree. Done means large repositories no longer produce ENOBUFS or a 500 response.