# worktree: Suppress bare \.git events explained by filtered sibling events \(\#61636\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/b1b412ddb3a15a1cd93250cf63f509fd8381e4b6)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: b1b412ddb3a15a1cd93250cf63f509fd8381e4b6

Requested commit: b1b412ddb3a15a1cd93250cf63f509fd8381e4b6

Commit: b1b412ddb3a15a1cd93250cf63f509fd8381e4b6

Tree: 995cf474290b65e9b20d05c6cbb130361c26c245

Author: Lukas Wirth

Committer: GitHub

## Message

```
worktree: Suppress bare .git events explained by filtered sibling events (#61636)

Fixes an infinite git-rescan loop on Windows introduced by #59876.

On Windows, creating or deleting a file directly inside .git updates the
directory's last-write time, so ReadDirectoryChangesW reports a bare
.git Changed event alongside the file's own event. Since #59876, bare
.git events schedule a git rescan (to cope with coalesced FSEvents on
macOS), so every filtered-out lock-file event still triggered a rescan
through its paired bare event. Because a rescan's own `git diff
--numstat HEAD` can take .git/index.lock (even under
--no-optional-locks, e.g. in jj-colocated repos whose index never
refreshes clean), each rescan re-triggered the next one, spawning ~9 git
processes per cycle, ~4 cycles/sec, indefinitely.

Bare .git events are now deferred while processing an event batch and
only trigger a rescan when the batch contains no filtered event for the
same git dir that explains the directory change. A standalone bare .git
event (the macOS coalescing case #59876 addressed) still triggers a
rescan, as does any batch containing a meaningful .git change.


Release Notes:

- N/A or Added/Fixed/Improved ...
```

## Parents

- [c2a610f7eb0aae50e2a0dd88972e7b6c9824bd7d](https://git.cafe/gitcafe/zed/commit/c2a610f7eb0aae50e2a0dd88972e7b6c9824bd7d?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/b1b412ddb3a15a1cd93250cf63f509fd8381e4b6?format=markdown)