7dcda48fdfe21b093a7b2c8039dfca2c28f89708
44
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Frank Loescheanddino
|
766d7a327a |
worktree: Fix global gitignore matching outside the worktree root (#62130)
# Objective When a worktree has no enclosing git repository, the `global-gitignore` check falls back to matching the raw, unbounded absolute path. This lets an ancestor directory outside the worktree, or the worktree's own root name, incorrectly match a bare global-ignore pattern (e.g. a global entry like `tmp` or `*.com`) and mark the entire worktree as ignored, which silently breaks project search and greys out every file in the project panel. Fixes #62126 Fixes #48887 ## Solution - In `Snapshot::ignore_stack_for_abs_path`, when no containing repository is found, fall back to the worktree's own root as the boundary for `IgnoreStack.repo_root`, instead of leaving it `None`. - This reuses the existing repo-root-relative matching logic in `IgnoreStack::is_abs_path_ignored` (already correct for the git-repository case since #61689) without needing any changes to `ignore.rs` itself: ancestors outside the worktree now correctly fail the prefix check and are treated as not ignored, while the global gitignore still applies to files and directories within the worktree. ## Testing - Added `test_global_gitignore_without_repository` in `crates/worktree/tests/integration/worktree_tests.rs`, covering both variants in one worktree: an ancestor directory outside a non-git worktree matching a global pattern, and the worktree's own root name matching one, while also confirming a file that matches the pattern from within the worktree is still ignored. - Verified the new test fails without the fix (reproducing both #62126 and #48887) and passes with it. - Ran the full `worktree` integration test suite (`cargo test -p worktree --test integration`); all tests pass. - Not tested on Windows or macOS, only Linux. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] Tests cover the changed behavior --- Release Notes: - Fixed global gitignore entries incorrectly matching directories outside the opened project and marking the entire project as ignored --------- Co-authored-by: dino <dinojoaocosta@gmail.com> |
||
|
Ali
|
ac9a03c4b9 |
Make opening large files use less peak memory (#62748)
# Objective Opening a file laods it twice. `decode_file_text` builds the whole file as a `String`, and that `String` stays alive alongside the finished rope while `text::Buffer::new` copies it in. The `Vec` behind it grows by doubling, so it also commits up to nearly the file's size again in capacity it never uses. Partially addresses #27283. ## Solution Add `decode_file_text_to_rope`, which streams the file in 1 MB blocks straight into a `Rope`, validating UTF-8 and normalizing line endings as it goes. The file is never fully held as a `String`. `LoadedFile::text` becomes a `Rope` carrying the `LineEnding` detected before normalizing, so `buffer_store` calls `Buffer::new_normalized`. ## Testing On a 729 MB SQL dump, peak memory fell 25% and CPU fell around 28%. tested on 5950x, win11. Release Notes: - Improved memory use when opening large files, reducing peak memory during load by roughly the size of the file itself. |
||
|
Dom Porada
|
ef973c67c0 |
Add support for the "..." entry in file_scan_exclusions (#62769)
## Objective `file_scan_exclusions` replaces the defaults instead of adding to them, so excluding one extra directory means restating all eleven default globs and never picking up defaults added in later Zed releases. ## Solution `file_scan_exclusions` now accepts the `"..."` entry, which expands to the value it overrides, so `["**/node_modules", "..."]` adds to the inherited globs instead of replacing them. Entries listed by name keep their position, and leaving `"..."` out still replaces the list outright, so existing settings behave exactly as they do today. ## Testing - Four unit tests in `crates/settings_content/src/project.rs` cover splicing versus replacing, accumulation across successive layers, and edge cases: a repeated `"..."`, an empty list clearing the value, and a bare `["..."]` leaving it unchanged. - To check by hand: set `"file_scan_exclusions": ["**/node_modules", "..."]` in user settings and confirm `node_modules` disappears from the project panel and file finder while `.git` and `.DS_Store` stay excluded. Remove `"..."` and confirm only `node_modules` is excluded. Repeat in a project's `.zed/settings.json` to confirm it splices the resolved user settings rather than the defaults. - Tested on macOS. This is platform-independent settings-merge logic with no OS-specific code paths, so I did not test Linux or Windows. ## Self-Review Checklist: - [x] I’ve reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed’s UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Added support for the `"..."` entry in `file_scan_exclusions`. Custom exclusions can now extend the defaults instead of replacing them. |
||
|
Kirill Bulatov
|
851bf3d499 |
Make file scanner less eager in non-git-tracked directory trees (#62583)
Fixes https://github.com/zed-industries/zed/issues/35780 Collab schema migration PR: https://github.com/zed-industries/cloud/pull/3422 The corresponding database schema migration has been created in the Cloud repo and applied to the production database. Before, Zed scanned each and every entry in the tree down from the directory it was opened in, except gitignored files and scan exclusions. The approach is unchanged, if Zed detects it was open inside a git repository: e.g. the directory open in Zed contains `.git` directory. For the rest of the projects, 2 optimizations are made: * Limit the depth of file scan traversal. Now, `file_scan_depth` (default `5`) restricts Zed from traversing any directory that has same number or more segments in its file path. Such directories behave similar to gitignored directories: their contents is not available in file finder, project search and project panel, but can be lazily traversed when the directory is expanded (e.g. project panel expands it or a nested file is open by path via terminal, etc.) To indicate that to the users, a status entry is shown firs time the limitation is hit in the project: <img width="858" height="133" alt="image" src="https://github.com/user-attachments/assets/7da6cfbb-98b4-4cc3-bf2a-8902a9597a15" /> * During the scan, any git repositories that are not direct children of the directory open in Zed (depth >= 2), are traversed and indexed normally, but their git metadata is never fetched eagerly. Only when Zed opens a buffer from that repo the git metadata is fetched and applied. All that combined now uses a way more moderate amount of CPU and RAM when opening `~`: <img width="1717" height="368" alt="Screenshot 2026-08-13 at 17 43 53" src="https://github.com/user-attachments/assets/ec83e2a9-f7cc-452b-8eb7-af158284ca4e" /> File scan inclusions and exclusions are considered still for such projects. Set `file_scan_depth` to `0` to enable old behavior. The setting is supported in the project settings, so custom values can be set based on the project's structure. --- Release Notes: - Fixed Zed using a lot of memory and CPU in large, non-git-tracked, directory trees |
||
|
Toru NayukiandKirill Bulatov
|
fa19fe3c5c |
project: Don't let a canceled caller leak a loading worktree forever (#61009)
# Objective `WorktreeStore::find_or_create_worktree` inserts the shared worktree-creation task into `loading_worktrees` and relies on the task it returns to each caller to remove that entry once creation resolves. But the creation task keeps running through the clone the map itself holds, while the map cleanup lives only in the callers' returned tasks. If every caller is cancelled before creation resolves, the resolved task stays in `loading_worktrees` forever, retaining the `Entity<Worktree>` captured in its result (a `Shared` task memoizes its output). Such a worktree can never be released: `remove_worktree` only unlists it, so its background scan keeps running and its snapshot keeps growing for the lifetime of the window. The stale entry also keeps `initial_scan_complete` permanently `false` (that flag is `loading_worktrees.is_empty() && …`). Callers are cancelled routinely — worktree creation is async and can take seconds on a large tree, while the tasks awaiting it are owned by UI that the user can close at any time (a tab or pane, a debugger panel resolving a path, an agent session, or the whole window). See the existing note in `crates/zed/src/zed.rs` that external-file worktrees are "released on file close". Observed in the wild: a home-directory worktree removed from the project kept scanning for hours and grew Zed past 45 GB; neither removing the folder nor ending the agent session freed it — only quitting Zed. (The scan-amplification half of that incident is #60988.) ## Solution Spawn the map cleanup as its own detached task, next to the map insertion, so a loading entry always leaves `loading_worktrees` when loading resolves regardless of what happens to the callers. The returned per-caller task is unchanged apart from no longer owning that cleanup. ## Testing - Added `test_worktree_released_when_creation_caller_is_cancelled`: it requests a worktree, drops the returned task immediately (as a cancelled caller would), lets creation complete, removes the worktree, and asserts the entity is released. It fails on `main` and passes with this change. - Full worktree-related project integration suite is green (45/45). ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - Fixed a memory leak where a worktree whose creation was requested by a since-cancelled task (e.g. a folder opened as its owning tab/panel/window closed) could never be released, leaving its background scan running and its snapshot growing for the lifetime of the window. --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
Henrique Ferreiro
|
bfcac04822 |
worktree: Anchor ignore rules at the repository they belong to (#62325)
Since #60772, a worktree's ignore rules are also applied to the directories above its root. Because of this, an `info/exclude` pattern naming one of those parent directories marks it as ignored, and with it the whole worktree below. Stop the walk at the repository containing the worktree root. Also skip exclude rules for paths outside the work directory they are anchored at, as `.gitignore` and global gitignore rules already do. Release Notes: - Fixed a worktree being reported as entirely ignored when its repository's `info/exclude` named one of the worktree's parent directories |
||
|
Kirill Bulatov
|
3692029a80 |
Bump rustc to 1.97 (#62395)
Release Notes: - N/A |
||
|
Dylan Arbouranddino
|
0ef4dd61eb |
worktree: Fix global gitignore on ancestors (#61689)
# Objective Fixes #61687 Prior to #60772, an `abs_path` outside the `repo_root` would cause a panic. That PR changed it to return the `abs_path` itself, preventing the panic, but allowing all parents of `repo_root` to be subject to the global ignore. This is not what git itself does. ## Solution - This change returns `false` when the `abs_path` is outside the `root_repo`, preventing the panic but also not returning the `abs_path` ## Testing - One in-memory test - Manual test by building Zed and confirming the project pane changes (pictured below) ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase ### Before, with the bug <img width="1430" height="814" alt="Screenshot 2026-07-26 at 11 44 11 AM" src="https://github.com/user-attachments/assets/66e3bb95-4f45-4fd9-a1e4-e7f253f092eb" /> ### After the fix <img width="1568" height="1042" alt="Screenshot 2026-07-26 at 12 34 58 PM" src="https://github.com/user-attachments/assets/588eb01d-830a-4c22-93c0-667742de90b6" /> Release Notes: - Fixed the project panel's global gitignore incorrectly matching parent directories of a repository --------- Co-authored-by: dino <dinojoaocosta@gmail.com> |
||
|
Lukas Wirth
|
fb813f70d6 |
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 ... |
||
|
Eric Holk
|
413b457870 |
worktree: Reload git state when a watcher rescan covers a repository (#61541)
# Objective When the OS file watcher loses sync (e.g. its event queue overflows under heavy fs churn), it drops pending events and reports a single `Rescan` event for the watched root. Git changes hidden behind such a rescan were silently lost, leaving the git panel and branch indicator stale until something else touched `.git`. Contributes to #13176. May fix #60102, though that report predates #60660 and may already be addressed by it on nightly (see Related PRs below). Two bugs caused this, and they masked each other: 1. **A rescan never triggered a git reload.** The `Rescan` event's path is the worktree root, not something inside `.git`, so it never populated `dot_git_abs_paths` in `process_events` — and since `.git` is excluded from entry scanning, the rescan produced no `.git` events either. The dropped git changes were simply never picked up. 2. **Re-scanning reset `git_dir_scan_id` to 0.** The snapshot diff detects git changes by comparing scan ids, so re-inserting the repository with a fresh id could wipe out a bump made earlier in the same scan cycle, swallowing the corresponding `UpdatedGitRepositories` signal. The masking is why these fixes land together rather than as two PRs: the root-rescan case in `test_dot_git_dir_event_does_not_suppress_children` only passed on `main` because the buggy scan-id reset made the snapshot diff fire spuriously. Fixing either bug alone turns that (currently green) test red. ## Solution - `process_events`: a `Rescan` event now schedules a git state reload for every repository whose git directory (`dot_git`, `common_dir`, or `repository_dir`) lies under the rescanned path, covering linked worktrees and gitfile repositories, including git dirs watched outside the worktree root. - `insert_git_repository_for_path`: carry the existing `git_dir_scan_id` forward when re-inserting a repository instead of resetting it to 0. Deliberately *not* bumped either: re-insertion is snapshot bookkeeping, not evidence of a git change — bumping would trigger spurious full reloads on non-lossy paths (explicit refreshes, path-prefix scans). Only `update_git_repositories` claims that git state changed. - `changed_repos`: a `debug_assert` enforcing that `git_dir_scan_id` never regresses, so future violations of this invariant fail loudly in tests instead of manifesting as a stale git panel. ## Testing New fault-injection infrastructure and tests: - `FakeFs::simulate_watcher_overflow` models the kernel's watch queue overflowing: buffered (undelivered) events are discarded and replaced by a single `Rescan` for the given root, mirroring FSEvents `kFSEventStreamEventFlagMustScanSubDirs`, inotify `IN_Q_OVERFLOW`, and Windows `ERROR_NOTIFY_ENUM_DIR`. - `test_watcher_overflow_rescan_reloads_git_state`: a git change whose events are lost to an overflow must still be picked up via the rescan (reproduces bug 1; fails on `main`). - `test_git_update_in_same_batch_as_rescan_is_not_lost`: a git event processed in the same batch as a rescan must not lose its scan-id bump to the repository re-insertion (reproduces bug 2; fails on `main`). - `test_random_git_updates_with_watcher_overflows`: randomized property test (100 iterations) asserting that every git state change is eventually signaled via `UpdatedGitRepositories` under random event batching, delays, and overflows. Fails on `main` within the first few seeds. - `test_random_worktree_changes` now also injects watcher overflows, extending its existing convergence property to rescan reconciliation of worktree entries (this already passed; the injection guards it going forward). Full `worktree` and `fs` suites pass. Verified the directed tests exercise the intended code paths via trace logging (the same-batch test hits `update_git_repositories` stamping followed by re-insertion, distinct from the overflow test where no `.git` event arrives at all). ## Related PRs The recent stale-git-state reports trace back to three distinct mechanisms that share one symptom. This PR addresses the third: - **Events never generated** — #60660 (merged, in this PR's base): Linux's non-recursive watcher missed nested `refs/` directories, so external commits/fetches produced no events at all. That PR (together with #60590, which explicitly rescans after Zed-initiated reset/fetch and touches only `git_store.rs`) fixed #60348. No overlap with this PR; a merge against current `main` is clean, and the refs-watching tests are disjoint from the overflow/rescan tests added here. - **Events coalesced** — #59876 (open, complementary): FSEvents can merge `.git` child events into a bare `.git` `Changed` event; the signal arrives, in a shape Zed ignores. @RemcoSmitsDev's review comment there describes this PR's failure mode and calls the two fixes complementary; this is effectively the follow-up promised in that comment. Both PRs touch the same region of `process_events`, so whichever lands second needs a trivial rebase, and #59876 flips the bare-`.git` expectation in `test_dot_git_dir_event_does_not_suppress_children` Case 2, which this PR preserves. - **Events dropped** — this PR: the watcher generated events but lost them to a queue overflow, and the resulting `Rescan` did not reach the git reload path. #59976 and #60098 (merged) reduced how often this happens; this PR makes git state recover correctly when it does. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - Fixed the git panel and branch indicator showing stale state after heavy file-system activity caused the file watcher to lose events |
||
|
Jiby JoseandEric Holk
|
281f6a5e02 |
Refresh git state on bare .git events (#59876)
# Objective Fix stale Git state in Zed when repository metadata changes are reported only as a bare `.git` directory event. On macOS, file watcher events can be coalesced such that Git operations only surface as a `Changed` event for the `.git` directory itself, rather than individual events for files like `.git/index` or `.git/HEAD`. Zed previously ignored bare `.git` directory events before scheduling a Git metadata refresh, which could leave the Git panel showing stale changes or an outdated history even though `git status` / `git log` reflected the latest state. ## Solution Treat meaningful bare `.git` directory events as Git repository updates before skipping them from normal worktree scanning. This preserves the existing behavior of not scanning `.git` as regular project content, while still notifying the Git repository tracking path that repository metadata may have changed. As a result, Git state such as `HEAD` and file statuses are refreshed when `.git` itself is the only watcher event. Updated the existing worktree test expectations so bare `.git` events now trigger `UpdatedGitRepositories`, while skipped files like `.git/index.lock` still do not. Added a test covering the full project/Git path: - repo initially has old `HEAD` and a modified file status - fake Git state is updated to represent a commit - only a bare `.git Changed` event is emitted - Zed refreshes the repository snapshot, observes the new `HEAD`, and clears the stale file status ## Testing The new tests cover the full project/Git path scenario described above. It fails without the fix and passes with the fix. Unfortunately, i was unable to reproduce the issue deterministically enough to test it end to end. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed stale Git panel state after repository metadata changes. Co-authored-by: Eric Holk <eric@zed.dev> |
||
|
Eric Holk
|
63a2ae3eee |
worktree: Apply outer repository excludes within nested repositories (#61492)
Closes TRA-162 When an entry's ignore stack is rebuilt from scratch (opening a file, file system events, a search that includes ignored files), `ignore_stack_for_abs_path` only consulted the `.git/info/exclude` rules of the nearest ancestor containing `.git`. For a path inside a nested repository, that nearest ancestor is the nested repository itself, so the outer repository's exclude rules were silently dropped: entries that were correctly ignored after the initial scan would flip to unignored the moment they were loaded or changed on disk, and from then on project search would surface them. This is the same class of bug that #60772 fixed for ancestor `.gitignore` files — this change extends the fix to `info/exclude` by collecting the exclude rules of every containing repository (outermost first, mirroring how ancestor gitignores are stacked) instead of just the innermost one. Added a regression test that models the affected layout: a bare clone and a linked worktree of it kept inside the repository, hidden via anchored patterns in the outer repository's `.git/info/exclude`. Release Notes: - Fixed project search returning results from inside nested repositories that are excluded by the containing repository's `.git/info/exclude` file. |
||
|
DinoandYara
|
23ee3ba37d |
project_panel: Add remote support for undo/redo system (#59709)
# Objective Add remote (SSH) and collaboration support for trashing and restoring files in the project panel, which in turn enables undo/redo of trash operations against remote and collab projects. Relates to #5039. ## Solution - Updated the project panel undo system to carry `TrashId` instead of `TrashedEntry`. - Using `TrashedEntry` could get hairy, as it includes paths, which wouldn't play too nicely when using, for exapmle, macOS as the client and Windows as the host. Using a simple identifier is much easier in this regard and simplifies implementation. - Enabled the Trash action and context-menu entry on remote projects, and removed the command palette filter in `ProjectPanel::new` that was still hiding the action on remote. - As far as I can tell, there isn't a reliable way to detect whether a given remote actually supports the OS trash, so we expose the action everywhere rather than guessing. On a remote without trash support the action will fail when invoked but this is a conscious tradeoff until we find a better way to handle this. - `fs` now tracks trashed files in a `SlotMap<TrashId, TrashedEntry>` on each `Fs` implementation. Trashed files are referenced by an opaque `TrashId` instead of passing a `TrashedEntry` around, which avoids serializing filesystem paths in remote messages. - Split the old `delete_entry(trash: bool)` API into distinct `trash_entry`/`trash_file` (returning a `TrashId`) and `delete_entry`/`delete_file` across `Project`, `Worktree`, `LocalWorktree` and `RemoteWorktree`. - This lets us drop the optional trash result (`Option<TrashedEntry>`) from the delete path and require a `TrashId` from the trash path. - Added new proto messages (`TrashProjectEntry`, `TrashProjectEntryResponse`, `RestoreProjectEntry`, `RestoreProjectEntryResponse`) to let clients request the host to trash or restore entries. - This deprecates `DeleteProjectEntry::use_trash`, but the host still honors it. An older collab peer may request trashing via that flag instead of the newer `TrashProjectEntry`. If the host ignored it, a newer host would permanently delete a file the user meant to send to the trash. The field will be removed in a later PR once all supported peers use `TrashProjectEntry`. ## Testing The following tests were introduced to ensure the new behavior is correctly tested: * `remote_server::remote_editing_tests::test_remote_trash_restore` – Tests trashing a project entry in remote * `remote_server::remote_editing_tests::test_remote_delete_project_entry_with_trash` – Test to ensure we continue respecting `DeleteProjectEntry::use_trash` until it is fully removed * `project_panel::tests::undo::trash_directory_undo_redo` – Not related to these changes but a nice to have as we were missing a test ensuring that trashing and then undoing and redoing it for a directory works as expected Besides these, the following scenarios were manually tested against a remote session on the same machine (macOS): - Trashing → Undo (Restore) → Redo (Trashing) - Batch Trashing → Undo (Batch Restore) → Redo (Batch Trashing) - Rename → Undo (Rename) → Redo (Rename) - Move → Undo (Move) → Redo (Move) - Batch Move → Undo (Batch Move) → Redo (Batch Move) ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [ ] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [ ] Performance impact has been considered and is acceptable Release Notes: - N/A --------- Co-authored-by: Yara <git@yara.blue> |
||
|
Lukas Wirth
|
6b6393fb0b |
Split out RelPath into a separate crate (#61029)
This is necessary to remove some `util` dependencies from crates, as well as better sharing for our projects. This also includes the WIP AbsPath abstraction as well as some bug fixes from internal tooling. Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Lukas Wirth
|
4e5b6c6b70 |
worktree: Watch .git/refs subdirectories for external ref updates (#60660)
On Linux and FreeBSD the native file watcher is non-recursive, so a watch on the .git directory itself does not report changes to files nested below it. Loose refs live in nested directories under refs, so external git commit, fetch, branch, and update-ref operations that don't also touch a direct child of .git (like the index) went entirely unnoticed. Watch every directory in the refs tree when a repository is inserted, and watch directories subsequently created under refs (new remotes, slash-named branches) as their creation events arrive. On platforms with recursive watchers these registrations dedupe against the existing recursive watch, making them free. --- Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Lukas Wirth
|
be9f38a892 |
worktree: Refresh all repositories sharing a changed git directory (#60664)
update_git_repositories mapped a changed .git path to a repository with find_map, so when several repositories share a git directory - a main checkout plus one of its linked worktrees in the same project worktree - a ref update under the shared common dir only bumped git_dir_scan_id on whichever repository iterated first, leaving the others stale until an unrelated event happened to refresh them. Collect every matching repository and bump each one. --- Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Jiby JoseandKirill Bulatov
|
7e786c264c |
Fix worktree entry IDs for symlinked files (#57846)
Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Closes #55792 Release Notes: - Fixed files in pnpm workspaces moving to symlinked `node_modules` paths after saving. --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
Anant GoelandAnthony Eid
|
f023a7e4a3 |
Fix worktree grouping for bare checkouts (#59968)
Summary - Track whether a worktree root is itself a linked Git worktree. - Use that metadata when computing project group keys so bare checkout worktrees group under the repository identity path. - Propagate the metadata through remote worktree protocols and add local/remote regression coverage. Background Bare checkout layouts can place linked worktrees under the repository identity directory, e.g. `/monty/.bare` with worktrees like `/monty/feature-a`. We were treating those linked worktree paths as separate project identities, which caused the sidebar to move agent threads under the active worktree instead of the shared repository group. We also exclude adding this to collab intentionally, we can open a different PR for that if we need to. Closes #59910 Closes AI-431 Test Plan - `cargo fmt --package project --package worktree --package remote_server --package workspace --package collab --package proto` - `git --no-pager diff --check` - `cargo test -p project test_project_group_key -- --nocapture` - `cargo test -p remote_server test_remote_root_repo_common_dir -- --nocapture` - `cargo test -p worktree remote_worktree -- --nocapture` - `cargo test -p workspace test_remote_project_root_dir_changes_update_groups -- --nocapture` - `cargo check -p collab` Self-Review Checklist: I've reviewed my own diff for quality, security, and reliability Unsafe blocks (if any) have justifying comments The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) Tests cover the new/changed behavior Performance impact has been considered and is acceptable Release Notes: - Fixed agent thread/sidebar grouping for Git worktrees backed by bare checkouts. --------- Co-authored-by: Anthony Eid <anthony@zed.dev> |
||
|
MartinYe1234
|
09415bf9e5 |
Include changed paths in remote UpdatedEntries events (#58157)
Include the changed paths in `UpdatedEntries` events emitted by remote worktrees. Previously a remote worktree emitted `Event::UpdatedEntries` with an empty changeset (`Arc::default()`), discarding the changed paths. The changeset now carries the real added/updated/removed paths, resolving removed entries against the previous snapshot. Release Notes: - Fixed file change events not reporting changed paths in remote projects |
||
|
Lukas Geiger
|
cdf9f6ff18 |
git: Avoid unnecessary git repo rescans when unrelated git files change (#59318)
# Objective
Zed triggers many git rescans whenever an outside git command modifies
files inside `.git` dir. This becomes especially problematic when
working on large repos or doing remote development on machines with slow
filesystems.
## Solution
Events for object writes, hook files, lock files, and the reflogs of
HEAD/branches/remote-tracking branches carry no git changes that Zed
cares about beyond what the ref or events already cover. So changes to
these files shouldn't trigger a full git rescan.
## Testing
I extended the existing unittests to add the additionally ignored
directories and lock files.
I also manually verified the changes by viewing the zed git debug logs
that get generated when running `git gc` on a freshly gc'ed repo.
Previously Zed triggered **7 worktree updates**, with these changes it
was reduced to **a single worktree update** which is due to
`.git/packed-refs` which we can't ignore.
**main:**
```
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:52+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:53+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
2026-06-13T13:56:54+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:54+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:54+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:54+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:55+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:55+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:55+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:55+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:56+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:56+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:56+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:56+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:56+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:56+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
```
**This PR:**
```
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] fetched remotes
2026-06-15T01:19:51+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] load merge details
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }```
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Reduced number of git operations when repository state changes outside of zed
|
||
|
Ben Kunkle
|
d124bd296b |
worktree: Don't eagerly remove watchers (#58692)
Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Closes #ISSUE Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Tianze Zhao
|
439d0bf281 |
Fix symlinked root rename event handling (#58624)
Fixes #58619. When a worktree is opened through a symlinked root, filesystem events can arrive rooted at either the opened symlink path or the canonical target path. The worktree event processing path already handled canonical target paths, but dropped events reported under the opened symlink root because it only derived relative paths from the canonical root. This PR adds a regression test that opens `/link -> /target`, renames `/link/subdir-a` to `/link/subdir-aa`, and verifies `subdir-aa/config.ini` remains visible in the worktree. The production fix accepts event paths under the opened worktree root as a fallback when deriving relative paths. Testing: - Verified the new regression test fails with only the test commit applied. - `cargo test -p worktree --test integration test_renaming_subdir_under_symlinked_root_keeps_children` - `cargo test -p worktree --test integration test_symlinks_pointing_outside` |
||
|
auwi-nordicandEric Holk
|
f00bcae75e |
Symlink scan option (#53646)
Adds option to always search/scan symlinks for more thorough coverage of #41887 issue This is a significant rewrite and more thoroughly reviewed and tested version of the old PR here: https://github.com/zed-industries/zed/pull/46344 The "never" option was removed from the old PR, since "expanded" is now the default. Perhaps "never" can be added as an option later if there's demand for it. Adding that option may resolve #48890 for instance. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable (significant impact with "always" option, but "expanded" is default) Release Notes: - Add option choose between including expanded symlinks or include all symlinks in project search (#41887) --------- Co-authored-by: Eric Holk <eric@zed.dev> |
||
|
|
c0c2df9c97 |
worktree: Fix linked worktree git dir event handling (#57782)
When a linked worktree receives fs events for its .git directory, the event path resolves to the per-worktree git dir (e.g. main_repo/.git/worktrees/<name>), not the .git directory itself or the common dir. The existing match only checked common_dir_abs_path and repository_dir_abs_path, causing the repository entry to be missed and then removed as stale. Add dot_git_abs_path to the match, and fix the staleness metadata check to use dot_git_abs_path (the actual .git entry) rather than common_dir_abs_path (which may be outside the worktree root). Extracted from https://github.com/zed-industries/zed/pull/53453 Release Notes: - N/A or Added/Fixed/Improved ... --------- Co-authored-by: Kieran Freitag <kfreitag@kieran.ca> Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
|
3c347c9dc4 |
Honor anchored patterns in .git/info/exclude (#57779)
Patterns in `.git/info/exclude` that contain a slash (e.g. `.claude/worktrees`) are anchored: Git matches them relative to the project root. Zed was instead matching them relative to the `.git/info/` directory that the file lives in, so they matched nothing and had no effect. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - Support anchored patterns in .git/info/exclude --------- Co-authored-by: Cole Miller <cole@zed.dev> Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
Max Brunsfeld
|
f43794ddc0 |
Fix the filtering of index.lock + COMMIT_MESSAGE FS events to work in linked worktrees (#57763)
Zed reloads a lot of data about a git repository any time any file changes inside of the `.git` directory, with the exception of a few known paths that we know do not warrant a reload, such as `index.lock` and `COMMIT_MESSAGE`. Previously, we ignored FS events for those files, but we used a specific path that only worked for the main worktree. This caused a lot of unnecessary reloads when using linked worktrees. Now we ignore those files in a general way, by their filename, so that the optimization applies to linked worktrees as well. @cole-miller Noticed this bug. Release Notes: - Fixed unnecessary reloading of Git state that could occur when editing in linked worktrees. |
||
|
Cole MillerandBen Kunkle
|
23f5b1cd75 |
Add some more logging to diagnose lost FS events and stale git state (#57173)
Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - N/A --------- Co-authored-by: Ben Kunkle <ben@zed.dev> |
||
|
Ben Kunkle
|
edf9271686 |
fs: Defer initializing poll watcher until after initial worktree scan (#56207)
Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Closes #56021 Closes #56100 Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Lukas Wirth
|
f0bdd3c4af |
Skip Git tracking for invisible worktrees (#55760)
Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Max Brunsfeld
|
1deb935c77 |
Fix handling of git repositories with an external git directory (#55402)
Closes https://github.com/zed-industries/zed/issues/54824 Previously, we always assumed that `gitdir` was an absolute path. Also, we did not correctly handle custom gitignore files that were configured via separate git directories. Release Notes: - Fixed failure to recognize git repositories where `gitdir` was expressed as a relative path. - Fixed handling of gitignores in git repositories that use a separate git dir. |
||
|
|
e4774ea2dc |
Respect .git/info/exclude in secondary worktrees (#51536)
Closes #50880 When a git worktree linked via a `.git` file (e.g. `gitdir: /repo/.git/worktrees/my-worktree`) was opened in Zed, entries in `.git/info/exclude` were not respected. This is now fixed. Before you mark this PR as ready for review, make sure that you have: - [x] Added a solid test coverage and/or screenshots from doing manual testing - [x] Done a self-review taking into account security and performance aspects - [x] Aligned any UI changes with the [UI checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) Release Notes: - Fixed `.git/info/exclude` not being respected when opening a secondary git worktree https://github.com/user-attachments/assets/f38df5dc-96eb-40a8-a77c-0932a2c8575b --------- Co-authored-by: Lukas Wirth <lukas@zed.dev> Co-authored-by: Lukas Wirth <me@lukaswirth.dev> |
||
|
Cole Miller
|
875f01dc9e |
git: Correctly filter ignored paths inside gitdirs on all platforms (#54548)
Previously the worktree's handling of events inside gitdirs looked like this: - First, deduplicate paths for which we received events by dropping any path that is a suffix of another one - Then, filter out events for deliberately ignored paths like `.git/index.lock` - Finally, collect a set of affected gitdirs based on the paths that remain This doesn't work on Windows, because when events occur for paths inside `.git` we also get an event for `.git` itself. The deduplication steps drops `.git/index.lock` before we get the chance to filter it out in the second step. This causes us to rescan git state unnecessarily on Windows. This PR fixes the issue by moving the filtering of ignored paths, and also the handling of `.git/info/exclude`, to just before the deduplication step. We also filter out events for the `.git` directory itself, so that if the batch of events looks like `[".git", ".git/index.lock"]`, we don't trigger `WorktreeUpdatedGitRepositories`. Self-Review Checklist: - [ ] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [ ] Tests cover the new/changed behavior - [ ] Performance impact has been considered and is acceptable Closes #ISSUE Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Tom Houlé
|
4823db5177 |
settings: Remove the project_name project setting (#54511)
The `project_name` worktree setting was added in #36713 to let users override the name shown in the window title. Its description ("The displayed name of this project. If left empty, the root directory name will be displayed.") suggests broader coverage, and #46440 reports the reasonable expectation that it should also apply in the project switcher. In practice the setting has only ever affected `Workspace::update_window_title`, so everywhere else (recent projects, the multi-worktree pane, ...) keeps falling back to the worktree root name. Rather than plumb the setting through each of those surfaces, I'm removing it. Having a project-level setting control how your editor displays the project has downsides. For example it means a checkout can dictate UI in someone else's Zed. The natural home for a custom display name is the workspace DB, set from the UI, which is what we should do if we want this feature back. If you want this back, the path forward is to store the display name in `WorkspaceDb`, expose a UI affordance to edit it, and read it from `update_window_title`, `recent_projects::get_recent_projects` / `get_open_folders`, and any other places that currently derive a display name from the worktree root. Closes #46440 Release Notes: - Removed the `project_name` project setting. It only ever affected the OS window title, and the expectation that it would show up in the project switcher and elsewhere is better served by a future UI-driven, per-workspace setting stored locally. |
||
|
prayansh_chhablani
|
1ebb960992 |
Fix zed irresponsive on symlinked directory events outside the editor (#50746)
Closes #48729, closes #27263, closes #45954 This PR aims to make zed responsive on symlinked directory events outside the editor. Before you mark this PR as ready for review, make sure that you have: - [ ] Added a solid test coverage and/or screenshots from doing manual testing - [x] Done a self-review taking into account security and performance aspects - [ ] Aligned any UI changes with the [UI checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) new-linked-folder is inside /zed-test/zed-project output of ls -ld new-linked-folder `lrwxr-xr-x 1 prayanshchhablani staff 42 28 Mar 23:20 new-linked-folder -> /Users/prayanshchhablani/new-target-folder` this shows new-linked-folder is a symlink folder whose target is new-target-folder which is outside the root dir of the project opened in zed. https://github.com/user-attachments/assets/ffebafc3-2fc4-4293-bdbf-3a894a45e276 Release Notes: - Fixed file watching of symlinks that point outside of the project/watched directory. Zed should now properly respond to changes in files in symlinked directories |
||
|
Eric Holk
|
b1b6d4acda |
worktree: Fix crash on rescan of an unregistered linked worktree commondir (#54215)
## 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 |
||
|
Danilo LealandNathan Sobo
|
4a41cc4bf0 |
agent_ui: Improve the new thread worktree UX (#53941)
Closes https://github.com/zed-industries/zed/issues/53262 - Remove the ability to pick a branch from the agent panel; delegate this to the title bar picker - Make the worktree creation earger, just as you selected whether you want to create it from main or current branch - Remove flicker when creating a new worktree and switching to a previously existing one - Improve some UI stuff: how we display that a worktree is creating/loading, the branch and worktree icons, etc. - Fixed a bug where worktrees in a detached HEAD state wouldn't show up in the worktree pickers A big part of the diff of this PR is the removal of everything involved with the `StartThreadIn` enum/the set up involved in only creating the worktree by the time of the first prompt send. Release Notes: - Agent: Improved and simplified the UX of creating threads in Git worktrees. - Git: Fixed a bug where worktrees in a detached HEAD state wouldn't show up in the worktree picker. --------- Co-authored-by: Nathan Sobo <nathan@zed.dev> |
||
|
|
9ffc384185 |
agent_ui: Unify draft and background threads into retained threads (#53737)
> **Foundation PRs:** #53732, #53733, #53734 — These three draft PRs contain the base refactors (retained workspaces, agent panel overlay split, ThreadId introduction) that this PR builds on. ## Goal Remove `DraftId` and merge `draft_threads` + `background_threads` into a single `retained_threads: HashMap<ThreadId, Entity<ConversationView>>` in `AgentPanel`. A draft is just a thread that hasn't sent its first message — no separate identity or storage needed. ## Changes ### agent_panel.rs - Remove `DraftId` / `DraftIdCounter` / the `Global` impl - Merge the two maps into `retained_threads` - Add `thread_id: ThreadId` field to `BaseView::AgentThread` - Rename methods: `create_draft` → `create_thread`, `activate_draft` → `activate_retained_thread`, `remove_draft` → `remove_thread`, etc. - Replace `clear_active_thread` with `show_or_create_empty_draft` - Update `update_thread_work_dirs` to sync `ThreadMetadataStore` paths when worktrees change - Keep `load_agent_thread(...)` cleanup so activating a real thread removes empty retained drafts ### sidebar.rs - Remove `active_entry` derivation from `rebuild_contents` (was racing with deferred effects) - Add `sync_active_entry_from_panel` called from event handlers instead - Simplify `ActiveEntry` — remove `ThreadActivation` struct, make `session_id` optional - Move `seen_thread_ids` to global scope (was per-group, causing duplicate thread entries) - Remove dead code: `clear_draft`, `render_draft_thread` - Generalize `pending_remote_thread_activation` into `pending_thread_activation` so all persisted-thread activations suppress fallback draft reconciliation - Set the activation guard before local persisted-thread activation switches workspaces - Make `reconcile_groups(...)` bail while a persisted-thread activation is in flight - On `ActiveViewChanged`, clear empty group drafts as soon as a pending persisted-thread activation resolves ### thread_metadata_store.rs - Make `ThreadMetadata.title` an `Option<SharedString>` with `display_title()` fallback - Add `update_worktree_paths` for batched path updates when project worktrees change ### Other crates - Update all `ThreadMetadata` construction sites and title display sites across `agent_ui` and `sidebar` ## Fallback draft invariant This PR now tightens the retained-thread invariant around fallback drafts vs real thread activation/restoration: - Fallback drafts are always empty - User-created drafts worth preserving are non-empty - While a persisted thread is being activated/restored/loaded, sidebar reconciliation must not create an empty fallback draft for that target group/workspace - Once the real thread becomes active, empty fallback drafts in that target group are removed This is enforced by the sidebar-side activation guard plus existing `AgentPanel` empty-draft cleanup after real-thread load. ## Tests Added and/or kept focused sidebar regression coverage for: - `test_confirm_on_historical_thread_in_new_project_group_opens_real_thread` - `test_unarchive_into_inactive_existing_workspace_does_not_leave_active_draft` - `test_unarchive_after_removing_parent_project_group_restores_real_thread` - `test_pending_thread_activation_suppresses_reconcile_draft_creation` Focused test runs: - `cargo test -p sidebar activate_archived_thread -- --nocapture` - `cargo test -p sidebar unarchive -- --nocapture` - `cargo test -p sidebar archive_last_thread_on_linked_worktree -- --nocapture` - `cargo test -p sidebar test_confirm_on_historical_thread_in_new_project_group_opens_real_thread -- --nocapture` - `cargo test -p sidebar test_unarchive_into_inactive_existing_workspace_does_not_leave_active_draft -- --nocapture` - `cargo test -p sidebar test_unarchive_after_removing_parent_project_group_restores_real_thread -- --nocapture` - `cargo test -p sidebar test_pending_thread_activation_suppresses_reconcile_draft_creation -- --nocapture` ## Test fix Fixed flaky `test_backfill_sets_kvp_flag` — added per-App `AppDatabase` isolation in `setup_backfill_test` so backfill tests no longer share a static in-memory DB. Release Notes: - N/A --------- Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com> Co-authored-by: Mikayla Maki <mikayla@zed.dev> |
||
|
|
8ce9ac3e6a |
project_panel: Add redo and restore support (#53311)
- Introduce `project_panel::Redo` action - Update all platform keymaps in order to map `redo`/`ctrl-shift-z`/`cmd-shift-z` to the `project_panel::Redo` action ### Restore Entry Support - Update both `Project::delete_entry` and `Worktree::delete_entry` to return the resulting `fs::TrashedEntry` - Introduce both `Project::restore_entry` and `Worktree::restore_entry` to allow restoring an entry in a worktree, given the `fs::TrashedEntry` - Worth pointing out that support for restoring is not yet implemented for remote worktrees, as that will be dealt with in a separate pull request ### Undo Manager - Split `ProjectPanelOperation` into two different enums, `Change` and `Operation` - While thinking through this, we noticed that simply recording the operation that user was performing was not enough, specifically in the case where undoing would restore the file, as in that specific case, we needed the `trash::TrashedEntry` in order to be able to restore, so we actually needed the result of executing the operation. - Having that in mind, we decided to separate the operation (intent) from the change (result), and record the change instead. With the change being recorded, we can easily building the operation that needs to be executed in order to invert that change. - For example, if an user creates a new file, we record the `ProjectPath` where the file was created, so that undoing can be a matter of trashing that file. When undoing, we keep track of the `trash::TrashedEntry` resulting from trashing the originally created file, such that, redoing is a matter of restoring the `trash::TrashedEntry`. - Refer to the documentation in the `project_panel::undo` module for a better breakdown on how this is implemented/handled. - Introduce a task queue for dealing with recording changes, as well as undo and redo requests in a sequential manner - This meant moving some of the details in `UndoManager` to a `project_panel::undo::Inner` implementation, and `UndoManager` now serves as a simple wrapper/client around the inner implementation, simply communicating with it to record changes and handle undo/redo requests - Callers that depend on the `UndoManager` now simply record which changes they wish to track, which are then sent to the undo manager's inner implementation - Same for the undo and redo requests, those are simply sent to the undo manager's inner implementation, which then deals with picking the correct change from the history and executing its inverse operation - Introduce support for tracking restore changes and operations - `project_panel::undo::Change::Restored` – Keeps track that the file/directory associated with the `ProjectPath` was a result of restoring a trashed entry, for which we now that reverting is simply a matter of trashing the path again - `project_panel::undo::Operation::Restore` – Keeps track of both the worktree id and the `TrashedEntry`, from which we can build the original `ProjectPath` where the trashed entry needs to be restored - Move project panel's undo tests to a separate module `project_panel::tests::undo` to avoid growing the `project::project_panel_tests` module into a monolithic test module - Some of the functions in `project::project_panel_tests` were made `pub(crate)` in order for us to be able to call those from `project_panel::tests::undo` ### FS Changes - Refactored the `Fs::trash_file` and `Fs::trash_dir` methods into a single `Fs::trash` method - This can now be done because `RealFs::trash_dir` and `RealFs::trash_file` were simply calling `trash::delete_with_info`, so we can simplify the trait - Tests have also been simplified to reflect this new change, so we no longer need a separate test for trashing a file and trashing a directory - Update `Fs::trash` and `Fs::restore` to be async - On the `RealFs` implementation we're now spawning a thread to perform the trash/restore operation Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Relates to #5039 Release Notes: - N/A --------- Co-authored-by: Yara <git@yara.blue> Co-authored-by: Miguel Raz Guzmán Macedo <miguel@zed.dev> Co-authored-by: Marshall Bowers <git@maxdeviant.com> |
||
|
Richard Feldman
|
8a3effce0f |
Gracefully handle when linked worktree .git path is outside worktree root (#53443)
In `update_git_repositories`, a `.git` path outside the worktree root can occur legitimately when `.git` is a gitfile (as in linked worktrees and submodules) pointing to a directory in the parent repo. Previously this triggered a `debug_panic!`, crashing debug builds. Now we skip the path with a `debug_assert!` that it is indeed a file (not a directory), so a genuine `.git` directory outside the worktree root would still be caught in debug builds. (No release notes because this is extremely hard to encounter until https://github.com/zed-industries/zed/pull/53215 lands) Release Notes: - N/A |
||
|
Max BrunsfeldandEric Holk
|
83e95f3c7e |
Maintain root repo common dir path as a field on Worktree (#53023)
This enables us to always different git worktrees of the same repo together. Depends on https://github.com/zed-industries/cloud/pull/2220 Release Notes: - N/A --------- Co-authored-by: Eric Holk <eric@zed.dev> |
||
|
Daniel Strobusch
|
877c2e1b0a |
worktree: Close single-file worktrees when file is deleted (#49366)
When a single-file worktree's root file no longer exists, the background scanner would previously enter an infinite retry loop attempting to canonicalize the path. This caused continuous error logging and resource waste. This fix detects when a single-file worktree root cannot be canonicalized (after attempting the file handle fallback) and emits a new Deleted event, allowing the worktree to be properly closed. This is most commonly encountered with temporary files, logs, and similar files that are opened in Zed and then deleted externally, but persist in the workspace database across sessions. Closes #34864 ## Test **Logs** from manual testing: ``` 2026-02-17T16:16:11+01:00 INFO [worktree] inserting parent git repo for this worktree: "tmp.md" 2026-02-17T16:16:17+01:00 ERROR [worktree] root path could not be canonicalized: canonicalizing "/Users/***/tmp/tmp.md": No such file or directory (os error 2) 2026-02-17T16:16:17+01:00 INFO [worktree] single-file worktree root "/Users/***/tmp/tmp.md" no longer exists, marking as deleted 2026-02-17T16:16:17+01:00 INFO [worktree] worktree root /Users/***/tmp/tmp.md no longer exists, closing worktree ``` Release Notes: - Fixed an issue where Zed would enter an infinite retry loop when the backing file for a single-file worktree was deleted |
||
|
Ben Kunkle
|
3795b2ce9d |
Handle Linux FS Rescan Events (#51208)
Closes #ISSUE Before you mark this PR as ready for review, make sure that you have: - [ ] Added a solid test coverage and/or screenshots from doing manual testing - [ ] Done a self-review taking into account security and performance aspects - [ ] Aligned any UI changes with the [UI checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) Release Notes: - N/A *or* Added/Fixed/Improved ... |
||
|
Lukas Wirth
|
b26bc404ea |
project: Always allocate WorktreeIDs on the remote client (#47936)
Closes https://github.com/zed-industries/zed/issues/40342 Release Notes: - N/A *or* Added/Fixed/Improved ... |
||
|
Piotr Osiewicz
|
00d72f2897 |
worktree: Use public-api-only tests (#47152)
- **settings: Do not leak type serialization into downstream crates** - **worktree: Separate integration tests into separate target** Release Notes: - N/A |