Eric Holk
b1b6d4acda
## Summary Fixes a crash I hit running Zed Preview against a checkout with many linked git worktrees. The panic was: ``` thread '<unnamed>' panicked at crates/worktree/src/worktree.rs:5334:25: update_git_repositories: .git path outside worktree root is not a gitfile: "/Users/eric/repo/zed/.git" ``` The `debug_assert!` in `update_git_repositories` was added in #53443 to catch the case where a `.git` path outside the worktree root is not a gitfile. The comment there explained that a `.git` outside the root should always be a gitfile (as in a linked worktree or submodule), so the assertion was meant to flag "should never happen" paths. But there's a second legitimate case: after a linked worktree's repository has been unregistered from `git_repositories` (for example because its gitfile was removed, or because the filesystem watcher for the common git dir lost sync and rescan-driven cleanup dropped the entry), a subsequent rescan event on the main repo's `.git` directory arrives at the linked worktree's scanner with the common git dir as the `dot_git_dir`. That path: - is outside the linked worktree's root (so it doesn't strip-prefix cleanly), and - is a real directory (not a gitfile), because it's the main repo's `.git`. So the assertion fires, but `continue` is already the right thing to do — there's simply nothing left for this scanner to do with a path that isn't its repository anymore. On macOS, the trigger in practice is the FSEvents API setting `MustScanSubDirs` / `UserDropped` / `KernelDropped` on an event (which `notify` surfaces as `need_rescan()`), which our `FsWatcher` converts into a `PathEvent { path: <watched path>, kind: Rescan }`. Because every linked worktree registers a watcher on the same shared common git dir, one kernel drop fans out into many rescan callbacks, and any one of them hitting a worktree whose repo was just unregistered triggers the panic. ## Changes - `crates/worktree/src/worktree.rs` — drop the `debug_assert!`, broaden the comment to cover both cases. - `crates/worktree/tests/integration/main.rs` — add a failing regression test that drives the exact sequence (repo unregistered, then a Rescan event on the common git dir) and asserts it doesn't panic. The two commits are split so the test commit reproduces the panic on its own, and the fix commit on top makes it pass. Release Notes: - N/A
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS, Linux, and Windows you can download Zed directly or install Zed via your local package manager (macOS/Linux/Windows).
Other platforms are not yet available:
- Web (tracking issue)
Developing Zed
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.
Sponsorship
Zed is developed by Zed Industries, Inc., a for-profit company.
If you’d like to financially support the project, you can do so via GitHub Sponsors. Sponsorships go directly to Zed Industries and are used as general company revenue. There are no perks or entitlements associated with sponsorship.