When I stage Changed in Git GUI, it raised an index error:
Updating the Git index failed.
A rescan will be automatically started to resynchronize git-gui.
error: could not spawn fsmonitor--daemon in the background
I can not find the reason and solution for this.
That should be addressed With Git 2.36 (Q2 2022), with a built-in improved fsmonitor.
See commit a3dfe97, commit 26b9f34, commit b05880d, commit 50c725d, commit ad2b54e, commit 86f7433, commit 8aa0209, commit 369f0f5, commit 08894d3, commit a00cdff, commit 148405f, commit dd77cf6, commit 518a522, commit 65723b3, commit 5ff01b1, commit 1448edf, commit bec486b, commit aeef767, commit 0ae7a1d, commit c284e27, commit 9dcba0b, commit f67df25, commit 62c7367, commit abc9dbc, commit 16d9d61, commit 3248486, commit 9c307e8, commit 1e0ea5c, commit d2bd862, commit 974c1b3 (25 Mar 2022) by Jeff Hostetler (Jeff-Hostetler).
(Merged by Junio C Hamano -- gitster -- in commit 439c1e6, 04 Apr 2022)
fsmonitor--daemon: use a cookie file to sync with file systemCo-authored-by: Kevin Willford
Co-authored-by: Johannes Schindelin
Signed-off-by: Jeff Hostetler
Teach
fsmonitor--daemonclient threads to create a cookie file inside the.gitdirectory and then wait until FS events for the cookie are observed by the FS listener thread.This helps address the racy nature of file system events by blocking the client response until the kernel has drained any event backlog.
This is especially important on MacOS where kernel events are only issued with a limited frequency.
See thelatencyargument ofFSeventStreamCreate().
The kernel only signals everylatencyseconds, but does not guarantee that the kernel queue is completely drained, so we may have to wait more than one interval.
If we increase the latency, the system is more likely to drop events.
We avoid these issues by having each client thread create a unique cookie file and then wait until it is seen in the event stream.