FSEvents infinite loop caused by git index writeback in lineChanges

[pacificleo]

What happened?

Upstream's new FSEvents file monitor watches the .git directory to trigger line-count updates dynamically. When a file change is detected, GitClient.lineChanges executes git diff HEAD --shortstat. However, because GIT_OPTIONAL_LOCKS=0 is not passed to the git invocation, git diff implicitly updates the .git/index cache. This index writeback triggers the FSEventStream again, creating an infinite background loop of file-system events and git diffs that drains the CPU and battery on large repositories.

Additionally, the O(N) lstat scan on large repositories is very slow, which can be fixed by passing -c core.fsmonitor=true.

Steps to reproduce

1. Open Supacode in a Git repository.
2. Make a file change.
3. Observe that WorktreeFileEventMonitor triggers continuously in an infinite loop due to .git/index writebacks.

Supacode version and build

Latest main

macOS version

macOS 26.0+

System locale

en_US

Mac hardware

No response

Relevant logs or screenshots

No response

Are you planning to fix this yourself?

• I intend to open a pull request once this is confirmed and marked ready.

Before submitting

• I searched existing issues and this is not a duplicate.
• I am on the latest available version of Supacode.
• I understand pull requests are closed until the issue is marked ready.
• I agree to follow this project's Code of Conduct.

[github-actions]

Thank you for filing this. A maintainer will review it and follow up here.

Please do not start any work or open a pull request until this issue is labeled ready. That label is a maintainer's go-ahead: a pull request opened against an issue that is not yet ready is labeled invalid until then. You will get a comment here the moment it is marked ready.

See CONTRIBUTING.md for the full flow.

[sbertix]

There is a reason why we didn't go the -c core.fsmonitor=true route when trying to address some of the performance issues of this, and it's because passing it as argument like that can be net-negative for performance (the first command does the full scan; you miss the argument once and the extension gets dropped from the index, so you've basically just paying for the cold-start every time).

git config core.fsmonitor true (and git config core.untrackedCache true), is something we could do instead, but it was "paused" because it feels too aggressive as a default, since it changes user configs (especially cause users that encounter the issue can already enable those themselves). We could have an option to enable those in Worktrees and per-repo settings, though. Wdyt?