I have a healthy suspicion of the performance of file-watchers. I hope this feature doesn’t make Git faster at the expense of “all filesystem operations crawl”.
This has been the way to get performance on a large Git repo for over a decade now, just not built into Git. It provides very good improvements even in environments that aren't the fastest, like laptops.
We deployed a system like this across hundreds of engineers in a reasonably sized monorepo and had zero complaints about system performance. While I don’t know the underlying architecture of inotify/etc, it seems to be very efficiently implemented.
It is of course not turned on by default. I don't know how bad the performance hit is, but it's an option so you get to choose the tradeoff. Either your git operations are slow or you take the small hit on all operations. If you spend all of your time working in a big repo it's probably going to be worth it.
I assume it is using one of the native platform APIs to detect file changes, which generally have some sort of overhead associated with them and then may or may not block on userspace code that can be badly behaved.
