[globnomulous]

Interesting idea. How does it, or how should it, perform in huge monorepos, where git performance suffers? I spend most of my time in a repo that contains hundreds of thousands of files, where just a simple `git status` can take >3.5 seconds even on very fast consumer hardware. (Thank God for sparse-checkout.)

[rohanucla]

This is actually the exact scenario we just spent the last few weeks optimizing for. On a 71K-file TypeScript monorepo, sem was previously choking entirely (DNF), and now completes in 6.5s with the topology cache warm. On a 100K-file generated fixture, sem impact went from 90s cold down to about 1s warm. The key was building a SQLite-backed cache that stores the dependency graph structure so repeat runs skip re-parsing unchanged files entirely.