This prepares for the keybinding hints PR.
To reproduce, press `ctrl-b` in a GPUI app with `ctrl-b h` and `ctrl-b
j` bindings, then call `window.blur()`. The live pending state clears,
but observers still report `ctrl-b`.
`Window::blur` now clears pending input and notifies observers after the
current effect cycle. I don't think we currently exercise this path in
Zed, and I was only able to reproduce it with an example GPUI app.
Release Notes:
- N/A
# Objective
- Add file-level hyperlink support for opening and copying hyperlinks
for Git remote source control to project panel and tabs
- Unify the language for Git remote hyperlinks across blame, project
panels, and tabs to be similar to GitLens' definitions (which are
commonly used in VS Code)
## Solution
- Updated the Git crate to expose relevant metadata to surface new
options within the editor
- Added new options for `Open File on Remote` and `Copy Remote File URL`
to project panel/file explorer and file tabs
- Altered the blame UI options to be consistent with new labels / more
clear
## Testing
- Ran `cargo run` to boot app and manually smoke test (see proof below)
- Added unit tests for this change
## 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
https://github.com/user-attachments/assets/d600ca4f-47e7-438c-90e1-f40124a606b4
---
Release Notes:
- Added options to open or copy whole-file permalinks from file tabs and
the Project Panel.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
# Objective
When an user uses the Project Panel to rename a file, it is possible to
change its path too. For example, renaming `README.md` to
`documents/README.md` will create the `documents/` directory, in case it
doesn't yet exist.
Unfortunately, even though undoing a rename operation is already
supported, we were not yet considering this scenario where directories
had been created specifically to support the rename. As such, when undo
was used, for the scenario above, we'd end up moving `README.md` back to
its original location but would leave the empty `documents/` directory
behind.
## Solution
Introduce two new operations and changes specifically for this use-case,
`Operation::CreateDir`, `Operation::RemoveDir`, `Change::DirCreated` and
`Change::DirRemoved`, which we can then batch together with the
`Operation::Rename` in case directories need to be created or removed.
An initial approach of just keeping the list of created directories in
the `Operation::Rename` and `Change::Renamed` variants was considered
but it would require all users of `Operation::Rename` to now set it,
even if they don't actually need it, like the drag and paste operations.
Having separate operations and change variants also makes it clearer
what these are meant to be used for.
Something else worth noting is that, for `Operation::CreateDir`, the
directory will only be created if it doesn't yet exist, otherwise we'll
ignore. Same happens for `Operation::RemoveDir`, where if the directory
is not empty, we don't delete it, as it's possible for new files to have
been added to the directory outside of Zed and we don't want to delete
those.
## Testing
Tested both manually as well as introduced a new test case
– `project_panel::tests::undo::rename_with_dir_undo_redo` .
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] 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
- [x] Performance impact has been considered and is acceptable
## Showcase
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Before</summary>
https://github.com/user-attachments/assets/15384fa8-9b94-495c-8992-19eee7a8f038
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/c5be9f38-a2b4-4acc-8a1e-178161e326bb
</details>
---
Release Notes:
- Fixed undoing a file rename leaving behind directories created by the
rename.
## 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.
Follow-up to #61852. The regression test I added there passes with or
without the fix.
The test creates the panel with `ProjectPanel::new` but never calls
`workspace.add_panel(...)`, so the panel is never rendered and its
filename editor never holds window focus. Deactivating the window then
blurs nothing, the project panel's `Blurred` handler never runs, and the
assertion holds trivially.
Add the panel to the workspace so it renders and its filename editor
takes focus, and assert that the editor is focused before deactivating,
so the test fails at an explanatory precondition rather than silently
going vacuous again.
Verified by running the new precondition without `add_panel`: it fails,
because the workspace's `on_focus_lost` fallback
(`crates/workspace/src/workspace.rs:1667`) reclaims focus from an editor
that was never rendered into the dispatch tree.
## Suggested .rules additions
> A GPUI test that depends on focus must put the view somewhere it can
actually be focused. Constructing a panel with `ProjectPanel::new` and
friends does not render it, so its editors never hold window focus and
every focus or blur assertion passes vacuously. Add it with
`workspace.add_panel(...)`, and assert the intended editor `is_focused`
before exercising blur.
Release Notes:
- N/A
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
# Objective
Ensure that, when users undo project panel operations, we don't trash
files with unsaved edits as that could lead to data loss, as outlined
[here](https://github.com/zed-industries/zed/issues/62243#issuecomment-5203625087).
Closes#62243
## Solution
Update `UndoManager::trash` to require confirmation before moving files
to the trash. For files with unsaved edits, users can save, discard, or
cancel the operation while clean files receive a standard trash
confirmation, same as shown when trashing a file through the Project
Panel.
This helps avoid the issue where, if an user undoes a file creation for
a file that has unsaved edits and then quits Zed, the edits that were
saved in memory, as well as the Project Panel history, will now be gone
and there's no way to recover the data.
Batch operations have also been updated to now show a single
confirmation before making filesystem changes, preventing partial
execution when cancelled and warning about unsaved edits.
Lastly, the trash/delete prompt building has been refactored in order
for the Project Panel and Undo Manager to share the same wording,
file-list truncation, and unsaved-change warnings.
## Testing
Tested both manually as well as added the following tests:
* `project_panel::tests::undo::undo_create_cancel_trash`
* `project_panel::tests::undo::undo_create_dirty_file`
* `project_panel::tests::undo::cancel_partial_trash_batch`
* `project_panel::tests::undo::batch_trash_warns_about_unsaved_changes`
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] 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
- [x] Performance impact has been considered and is acceptable
## Showcase
The screen recording below shows the trash confirmation dialog on both a
clean and dirty files, on both undo and redo flows.
https://github.com/user-attachments/assets/0f9b96f5-0357-4e3f-8ec2-141486942c89
---
Release Notes:
- Fixed issue with undoing or redoing project panel operations that
could lead to a file with unsaved edits being trashed without
confirmation.
Splits the crate graph.
Before, the compilation graph: `editor → picker_preview → search →
project_panel → open_path_prompt → recent_projects → title_bar →
collab_ui → zed`
After, the compilation graph: `editor → picker_preview → search →
agent_ui → sidebar → zed`
With sccache disabled and project fully built, `touch
crates/editor/src/editor.rs` and `cargo build -p zed` took time
Before (0500fd9ee9): 13.19s
After: 11.85s (-10.2% speed up)
Each commit contains a separate compilation instructions, and a test in
the final commit.
The main approach is to split coupled crates and replace them with
`zed_actions` and move some shared functionality into `git_ui_core` new,
shared module.
I've also tried to add a test to prevent common pitfalls, but not sure
I'm happy with the end result — can remove it if it looks too synthetic.
Release Notes:
- N/A
# Objective
Let git indicators — the editor gutter, file colors, and `git::Diff` —
show all changes on the current branch relative to its merge base with
the default branch, instead of only uncommitted changes.
Supersedes #60398; thanks to @samuelcolvin for the original
implementation and motivation.
Closes FR-135
## Solution
- New `git.diff_base` setting (`"head"` | `"default_branch"`), applied
live and toggleable per session from the editor controls menu ("Diff
Against Default Branch").
- Statuses come from a real merge-base-to-worktree tree diff (`git diff
--merge-base`), so local edits that revert branch changes correctly show
as unchanged.
- `GitStore` shares one `DiffBufferList` per repository with the Branch
Diff view; `repo_snapshots` and `project_path_git_status` keep returning
index/worktree truth, while display surfaces use separate `display_*`
APIs.
- `BufferDiff` now records what its base is (`DiffBaseKind`); hunks
whose base isn't HEAD are read-only in the gutter — stage/restore
buttons and keybindings are inert, so committed work can't be silently
rewritten.
- `git::Diff` follows the setting; new `git::DiffHead` always opens the
HEAD diff; `git::BranchDiff` is renamed `git::DiffBranch` (deprecated
alias kept).
Tradeoffs / known limitations:
- Hunk-level staging is unavailable while in `default_branch` mode
(whole-file staging via the git panel still works). Staging just the
uncommitted sub-ranges of a branch hunk is a follow-up.
- Remote hosts running an older server ignore the new
`GetTreeDiff.includes_worktree` proto field and degrade to
committed-changes-only branch diffs.
- Repositories with no resolvable default branch fall back to
HEAD-relative behavior; a failed first resolution retries on the next
branch-list change.
## Testing
- Real-git-repo tests for the merge-base-to-worktree diff's edge cases:
files recreated after index deletion, committed deletions recreated on
disk, and symlinks.
- GPUI tests for status semantics (a branch change reverted on disk
shows clean), `git::Diff` routing, live setting changes, and read-only
hunk enforcement (restore/stage leave buffer and index untouched).
## 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:
- Git: Added a `git.diff_base` setting (`"head"` or `"default_branch"`)
that makes the editor gutter, file colors, and diff view show all
changes on the current branch since its merge base with the default
branch, instead of only uncommitted changes.
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
## Description
Adds native macOS file drag out support for Project Panel entries. Local
file paths are resolved only when a drag gesture starts, remote or
missing paths are skipped, and unsupported platforms keep the default
no-op behavior.
The macOS implementation starts an AppKit drag session with file URL
pasteboard items, allows Finder and other external apps to choose copy
or move, keeps in-app GPUI drag/drop behavior in control for internal
drags, and clears the active drag state when the native session ends.
https://github.com/user-attachments/assets/42909389-1a32-4574-a200-9a14b913f55f
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
- [ ] Performance impact has been considered and is acceptable
Closes#55370
Release Notes:
- Added support for dragging files from the Project Panel to external
macOS apps.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Closes#39286
## Problem
Switching the keyboard layout on Wayland (e.g. GNOME's Super+Space)
makes the compositor briefly grab the keyboard, which deactivates the
Zed window. GPUI reports window deactivation as a blur of the focused
element (`WindowFocusEvent` is emitted with an empty
`current_focus_path`), so controls that dismiss or cancel on blur
treated it as the user abandoning them. The same happens when switching
to another app window. As discussed in #39286 with @MrSubidubi, the
desired behavior is to keep these controls open and focused across
window deactivation.
## Fix
Guard the blur-driven cancel/dismiss handlers with
`window.is_window_active()`, following the pattern established for
pickers in #41320:
- Project panel: in-progress rename / new file / new directory inputs
are no longer cancelled when the window is deactivated
- Collab panel: in-progress channel rename is no longer cancelled
- Go to Line: the dialog is no longer dismissed
In-window focus changes (clicking elsewhere, Escape) keep the existing
commit/cancel semantics. The terminal tab rename needed no change: it
re-checks `FocusHandle::is_focused`, which reads `window.focus` and that
survives deactivation. Command palette, file finder, and outline were
already fixed by #41320.
Added a regression test (`test_rename_survives_window_deactivation`)
that starts a rename, deactivates the window via the test platform, and
asserts the edit state survives.
Two milder siblings were left unchanged to keep this PR focused,
flagging them for a maintainer decision: the notebook markdown cell
exits edit mode on blur (`crates/repl/src/notebook/cell.rs`), and the
diagnostics view prunes diagnosticless buffers on blur
(`crates/diagnostics/src/diagnostics.rs`).
Longer term it may be worth carrying the blur cause in the event itself
(e.g. a `FocusMoved` vs `WindowDeactivated` reason on `FocusOutEvent`
and `EditorEvent::Blurred`), so each handler has to state which causes
it handles instead of relying on an opt-in guard; happy to file a
separate issue for that.
## Before
https://github.com/user-attachments/assets/9eec1bb5-1881-4b3a-80ef-a287e23219ca
## After
https://github.com/user-attachments/assets/49b8775c-175a-4882-835d-871432c0b315
## Suggested .rules additions
> Handlers that cancel or dismiss UI on blur (`EditorEvent::Blurred`,
`on_blur`, `on_focus_out`) must check `window.is_window_active()` first:
GPUI reports window deactivation (app switch, layout switcher grabbing
the keyboard) as a blur of the focused element, and dismissing there
loses user input.
Release Notes:
- Fixed in-progress file renames, channel renames, and the Go to Line
dialog being cancelled when the window is deactivated, e.g. by a
keyboard layout switch on Wayland or by switching to another application
([#39286](https://github.com/zed-industries/zed/issues/39286)).
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
# Objective
A failed restore, for example, a collision at the original path, used to
remove the `TrashedEntry` from the registry before attempting the
operation, so any later attempt with the same `TrashId` would report an
`AlreadyRestored` error, even though the item still sat in the system
trash.
## Solution
Update both `RealFs::restore` and `FakeFs::restore` to remove the entry
only after the restore succeeds. There's also a small unrelated change
in `ProjectPanel::drag_onto` to log, rather than silently discard, a
failed undo-history record in the project panel, matching existing call
sites.
## Testing
Introduced a new test for these changes
– `restore_can_be_retried_after_collision` .
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] 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
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A
Closes#60985
Clicking a link to a Markdown file from a Markdown preview now opens the
target in a preview instead of the raw editor buffer. `alt`-click opens
the raw source editor instead.
- If there exists existing preview of that file it is reused. A link
back to the file being previewed navigates in place.
- `file.md#heading-slug` scrolls the preview to the linked heading.
- `file.md:42:5`, `file.md#L42` and `file.md#L42C5` open the preview
scrolled to that position with the cursor placed there. Non-Markdown
targets keep the existing behavior from #60864 (raw editor at the
position).
Added tests covering these and more cases.
Release Notes:
- Improved Markdown preview links: links to Markdown files now open in a
preview (scrolled to the linked heading or position) instead of the raw
file, and `alt`-click opens the raw source instead.
- Fixed GitHub-style `#L<line>C<column>` link fragments not placing the
cursor at the linked position.
this pr enables opening a specific line in a diff using zed's cli
Release Notes:
- refactor: add possibility to open specific line in a diff using the
cli
---------
Co-authored-by: Cole Miller <cole@zed.dev>
# Objective
Fix error shown when attempting to undo/redo operations on excluded
files, for example, undoing a creation of a file in an excluded path.
## Solution
Since `worktree::Snapshot::entry_for_path` always returns `None` for
excluded files, these changes will simply avoid calling
`UndoManager::record` in `ProjectPanel::confirm_edit` if the created
entry is excluded. This can be confusing if the user is renaming a file
to another path that is excluded, as that will not be recorded and can't
be undone but we accept it as a limitation for now and will document
that.
In the future we can potentially support undoing of operations for
excluded file paths but that would mean not only introducing new methods
that operate directly on the absolute path instead of the entry id, as
well as changes to the proto messages, in order to ensure it's also
fixed in remote and collab.
## Testing
Tested manually, as shown in the "Showcase" section below and also
introduced a test for this –
`project_panel::tests::undo::excluded_create_is_not_recorded` .
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] 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
## Showcase
<details>
<summary>Before</summary>
https://github.com/user-attachments/assets/7f8fca3e-2716-40bb-95db-c7119bb39b83
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/47b0322e-a323-4648-8a56-6e96266888d3
</details>
---
Release Notes:
- N/A
# Objective
Users in a read-only project should have no permission to create,
rename, move, trash or delete files, as such, they should also have no
way to undo or redo these actions. These changes ensure that the
listeners for both `project_panel::Undo` and `project_panel::Redo` are
only registered if the project is not read-only.
## Solution
The `ProjectPanel` listeners for both the `Undo` and `Redo` actions were
not gated behind the existing `!Project::is_read_only` call, on
`ProjectPanel::render`, so these changes move the listeners inside that
check.
## Testing
Currently, there isn't an easy way to manually test this, as these
actions were already disabled in collab and the easiest way to get into
a read-only project is connect as a collab guest. However, in order to
ensure this continues being asserted once we remove the collab
restriction, the
`project_panel::tests::undo::undo_redo_unavailable_for_read_only_collab_guest`
test has been added.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] 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
# 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>
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 ...
Reordering worktree roots by drag-and-drop had silently broken: a
worktree-root filter added to `disjoint_entries` for delete-safety
stripped roots before the drop handler could see them, so root-to-root
drops never reached the existing `move_worktree` reorder path.
This PR is the minimal regression fix:
- Move the worktree-root filter out of `disjoint_entries` and into
`disjoint_effective_entries` (used by cut/copy/delete), so drag-and-drop
keeps seeing roots and single-root reorder works again via the existing
`move_worktree` path.
- Filter worktree roots out of `drag_onto`'s copy branch, so holding the
copy modifier over a drag that contains a root no longer returns `None`
from `create_paste_path` and silently cancels the whole copy.
- Add `test_drag_worktree_root_reorders_worktrees` exercising the
drag-onto reorder flow end to end.
The larger feature work (multi-root group reordering, blank-area "send
to end", copy-mode drag feedback, and syncing worktree order to
collaborators) has been split into a separate follow-up PR so this fix
can land quickly. Note that worktree order was intentionally not synced
during collaboration, so that change is discussed separately.
Closes#46699
Release Notes:
- Fixed drag and drop to reorder worktrees
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
# Objective
Provide a means of quickly opening a permanent tab from project panel
instead of a preview tab.
Implements #51866 (_Middle click to open file in a new tab_ with 18×↑)
which is also part of #31822 (_Middle Click Improvments_) titled "middle
clicking on a file in the project panel should open the file in a
non-transient state".
With `preview_tabs.enable_preview_from_project_panel` enabled, a click
in the project panel opens a preview tab, and there's no easy gesture to
open a permanent one instead, simplest one currently being a double
click. VS Code and VSCode-based editors recognize middle mouse click as
a way to open a permanent tab since 2016 (microsoft/vscode#14453).
## Solution
Wired up an `on_aux_click` handler for project panel entries:
middle-clicking a file opens it in a permanent tab and focuses it,
regardless of the preview tabs setting.
Added a line to `docs/src/project-panel.md` to reflect the behavior.
## Testing
- Manually tested on Windows: middle click opens a permanent tab,
promotes an existing preview tab to a permanent one if already open,
does nothing for directories
- Haven't tested on macOS/Linux
## Self-Review Checklist:
- [ ] 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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
<details>
<summary>Click to view showcase</summary>
https://github.com/user-attachments/assets/2de5f23d-637f-4ffc-8d03-02dc11714af4
</details>
---
Release Notes:
- Added support for middle-clicking a file in the project panel to open
it in a permanent tab instead of a preview tab
This PR adds adjustments to the tree view, making it more consistent
with all other tree view displays in the app (e.g., displaying indent
guides, removing chevron toggle, etc.), and also fixes an issue where
the commit message scrollbar was scrolling up with the message.
Release Notes:
- N/A
Release Notes:
- Fixed clear drag overlay when external drag ends outside window
When dragging files from macOS Finder over the project panel and then
dragging back to Finder, the drag overlay remained visible because the
drag state was not properly cleaned up.
The root cause was that only `draggingExited:` was handled, but not
`draggingEnded:`. On macOS:
- `draggingExited:` is called when the drag leaves the window area
- `draggingEnded:` is called when the drag operation ends entirely
When a user drags a file back to Finder and drops it there,
`draggingEnded:` is called but was not being handled.
---------
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
## Summary
On Windows, `trash::delete_with_info` can return an error even when the
file was successfully moved to the Recycle Bin.
This is caused by a race condition in the `trash` crate: after
`IFileOperation::PerformOperations` completes, it re-binds the trashed
item via `SHCreateItemFromParsingName` to read its metadata, but the
shell's virtual namespace cache may not yet reflect the new item,
producing an error. Previously, the delete loop propagated this error
and aborted the entire batch. The outer `detach_and_log_err` swallowed
the error, so the user received no feedback.
This PR handles each entry independently: entries that fail to delete
are skipped, the loop continues, and undo history is recorded for the
entries that succeeded.
The upstream root cause (the post-operation re-bind race in
`zed-industries/trash-rs`) will be addressed separately.
Before:
https://github.com/user-attachments/assets/59a95ac5-098b-42dc-bffb-f3240c6b966d
After:
https://github.com/user-attachments/assets/0cd6c0b3-2ee3-4bf2-a243-3e8a83d05dd7
## Test plan
- [ ] Select multiple files in the project panel on Windows
- [ ] Trash them (right-click > Move to Trash, or `Delete` key)
- [ ] Confirm all selected files are deleted, even if one triggers the
trash-crate race
- [ ] Undo restores the files that were successfully trashed
Release Notes:
- Improved handling of failed trash or delete operations in the Project
Panel in order to display a toast informing the user that some files
could not be trashed or deleted
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Add `ExpandAllEntries` action, keybinding, and right-click context menu
entries for expand/collapse all in the project panel.
- Add `ExpandAllEntries` action + handler + `expand_all_entries()`
method
- Add `cmd-right` / `ctrl-right` keybinding for `ExpandAllEntries`,
mirroring
the existing `cmd-left` for `CollapseAllEntries`
- Add "Expand All" to root-entry and folder right-click context menus
- Add keybinding hint to root-entry "Collapse All" context menu entry
- Per-worktree behavior: context menu actions affect only the selected
worktree,
subfolder "Expand All" expands from that folder down
# Objective
The project panel had no discoverable way to expand or collapse all
entries. The only ways were keyboard shortcuts (`cmd-left` for collapse
all)
or the right-click context menu. The global `ExpandAllEntries` shortcut
(`cmd-right`) was also missing. This PR adds that shortcut and exposes
both actions in the context menu so users learn the keybindings while
keeping the UI minimal.
## Solution
- Add `ExpandAllEntries` action + handler + `expand_all_entries()`
method
- Add `cmd-right` / `ctrl-right` keybinding for `ExpandAllEntries`
(global),
mirroring the existing `cmd-left` for `CollapseAllEntries`
- Add "Expand All" to the right-click context menu for both root entries
and
subfolder entries
- Update root-entry "Collapse All" to show its keybinding hint via
`.action(Box::new(CollapseAllEntries))`
- **Per-worktree behavior**: each root entry's context menu actions
affect
only that worktree, subfolder "Expand All" expands from that folder down
## Testing
- Added 6 GPUI tests in `project_panel_tests.rs`:
- `test_expand_all_entries`: single worktree
- `test_expand_all_entries_multiple_worktrees`: global expand across
worktrees
- `test_expand_all_entries_via_window_dispatch`: action dispatch path
- `test_per_worktree_expand`: expand only the clicked worktree
- `test_per_worktree_collapse`: collapse only the clicked worktree, keep
root visible
- `test_expand_all_entries_with_auto_fold`: expand with auto_fold_dirs
- Ran `cargo test -p project_panel`: 106 pass
**Manual testing for reviewers:**
1. Open a project with nested directories and open the Project Panel
2. Right-click a root entry, confirm "Expand All" and "Collapse All"
appear
with their keybinding hints (`⌘→` / `⌘←`)
3. Right-click a subfolder, confirm "Expand All" and "Collapse All"
appear
4. Click "Expand All" on a subfolder, confirm only that folder's subtree
expands
5. Click "Collapse All", confirm children collapse but the root stays
visible
6. Open a multi-folder workspace. Right-click the second root and click
"Expand All", confirm only that folder expands
7. Press `cmd-right` (or `ctrl-right`), confirm all worktrees expand
globally
Tested on macOS only. Linux and Windows should behave the same since
there
is no platform-specific code.
## 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
https://github.com/user-attachments/assets/adc501d7-8e3a-4687-aef0-dc00426d232d
---
Release Notes:
- Added `Expand All` and `Collapse All` to the project panel right-click
context menu with keybinding hints.
- Added `cmd-right` / `ctrl-right` keybinding to expand all entries.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Opening a markdown file from the project panel used to require four
steps:
- click the file (opens raw editor)
- right-click the editor tab
- select "Open Markdown Preview"
- then close the raw editor tab
This PR shortcuts that to a single right-click (or keypress) from the
project panel.
Right-clicking a markdown file in the project panel now shows an **Open
Markdown Preview** option. Selecting it opens the rendered markdown
preview directly — no raw editor tab is left behind. The same shortcut
used in the editor (Cmd+Shift+V on macOS, Ctrl+Shift+V on Windows/Linux)
also works when focus is in the project panel.
## How it works
- **Context menu**: `OpenMarkdownPreview` action is registered and
surfaced in the right-click menu only for `.md`/`.markdown` files.
- **Keybinding**: `cmd-shift-v` / `ctrl-shift-v` bound to
`project_panel::OpenMarkdownPreview` in the `ProjectPanel` context,
mirroring the existing editor binding.
- **Loading**: The file is opened via `open_path_preview` with
`focus_item: false, activate: false`, so the raw editor is loaded into
the buffer system but never becomes the visible tab.
- **Preview construction**: `MarkdownPreviewView::create_markdown_view`
is called directly (no `dispatch_action` indirection, which would have
been deferred and caused a race). The preview is added to the active
pane and the raw editor tab is removed atomically in one synchronous
pane update.
- **Pre-existing tabs**: Before loading, all panes are checked for an
existing item at the file's project path. If the file is already open in
raw mode, `remove_item` is skipped — the existing tab is left untouched.
Release Notes:
- Added "Open Markdown Preview" context menu item to Project Panel
markdown entries.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Tom Houlé <tom@tomhoule.com>
Share marked selections across rendered project panel entries and defer
drag-related path cloning until drag and drop rendering is enabled. Also
defer symlink path string conversion until tooltip creation.
Release Notes:
- N/A or Added/Fixed/Improved ...
# Objective
- Renaming a folder whose name contains a dot pre-selects only the text
before
the last dot, treating the suffix as if it were a file extension.
- Fixes#59294
## Solution
- `ProjectPanel::rename_impl` computed the rename editor's initial
selection with
`Path::file_stem().len()` for every entry. For a directory such as
`my.folder`,
`file_stem()` returns `my`, so only `my` was selected.
- Directories have no extension, so select the whole name for them.
Files keep
the existing behavior (the last extension is left unselected for quick
renames).
## Testing
- Added `test_rename_folder_with_dot_selects_whole_name` in
`project_panel_tests.rs`.
It fails before the change (folder selection ends at offset 2 of
`my.folder`) and
passes after (offset 9, the whole name); it also asserts a file still
leaves the
last extension unselected.
- `cargo test -p project_panel` — all 100 tests pass.
- `cargo clippy -p project_panel --all-targets --all-features -- --deny
warnings` and
`cargo fmt -p project_panel -- --check` are clean.
## 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 and icon
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed renaming a folder with a dot in its name selecting only the part
before the dot.
---------
Co-authored-by: Finn Evers <finn.evers@outlook.de>
The implementation for this is just below and the comment should have
been long removed.
At least one TODO less in the 100 existing ones 🎉
Release Notes:
- N/A
This is an unsolicited contribution, I hope that's ok. The feature is
small and I didn't want to open a discussion just for this.
There was no way to write to `.git/info/exclude` from Zed, so I added
one.
The "Add to .gitignore" action in the project panel and git panel
context menus is now grouped under a "Git" submenu, with a new "Add to
.git/info/exclude" action next to it.
Both actions:
- skip the write if the pattern is already there
- make sure there's a trailing newline
- show an error toast if something goes wrong
- fail gracefully on remote repositories
In the git panel both entries are disabled unless the file is untracked,
same as the gitignore action was before.
The write logic is shared via a small private helper, covered by two
unit tests.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [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:
- Added `Add to .git/info/exclude` option under a new `Git` submenu in
the project panel and git panel context menus, alongside the existing
`Add to .gitignore` action.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
When handling click events on entries in project panel, we were
returning early if the click was the one that brought the Zed window
into focus. This effectively ignored the click action on the item. This
leads to two clicks being required to act on an item in the project
panel if the Zed window is out of focus. The existing behaviour is also
inconsistent with other UI controls, where clicking on them when the
window is out of focus actually acts upon them.
This behaviour was introduced in
https://github.com/zed-industries/zed/pull/9553.
This PR fixes the click handler on the entries so that events with
`first_focus() == true` are no longer ignored.
Before:
https://github.com/user-attachments/assets/d51ec11d-c47a-4ea3-af6d-63bf6daf3c44
After:
https://github.com/user-attachments/assets/87b9e6a8-9ef0-463f-8557-e15d25b519ca
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] 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)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes#58261
Release Notes:
- Fixed project panel needing a second click to change the file if the
window is not in focus
cc @Anthony-Eid
## Why
This is the first step in moving the Git Graph work into the Git UI
crate before continuing with follow-up refactors and feature work. The
goal is for Git UI components and shared Git UI helpers to live in one
crate, so future changes to the Git Graph can reuse existing `git_ui`
code instead of duplicating it.
This PR is not only a filesystem move. While moving `git_graph` into
`git_ui`, a few small dependency and helper boundaries had to change:
- `git_graph` and `git_ui` both needed the same remote parsing and
commit tooltip construction behavior, so those pieces are now shared
from `git_ui`.
- `git_graph` previously depended on `project_panel` to resolve
file-history actions from the project panel selection. After moving
`git_graph` into `git_ui`, keeping that dependency would create an
undesirable `git_ui` -> `project_panel` relationship. The
project-panel-specific action forwarding now lives in `project_panel`,
and calls into exported `git_ui::git_graph` helpers instead.
- `git_graph` initialization now happens through `git_ui::init`, so
downstream crates only need to initialize `git_ui`.
This prepares the codebase for the next planned PRs: splitting the large
`git_graph.rs` implementation into smaller pieces, then adding Git Graph
features such as keeping the main branch lane at index `0`.
## License removal
The removed `crates/git_graph/LICENSE-GPL` file was a symlink to the
repository root `LICENSE-GPL`. The moved code is now inside `git_ui`,
which is also licensed as `GPL-3.0-or-later` and has its own
`LICENSE-GPL` symlink to the same root license file. The code did not
move to a differently licensed crate; it remains covered by the same GPL
license.
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: Anthony Eid <anthony@zed.dev>
I use the One Dark theme, so to actually test if my fix worked, I had to
also do:
```jsonc
"experimental.theme_overrides": {
"warning": "#ff0000",
"modified": "#00ff00",
},
```
| Before | After |
|--------|--------|
| <img width="676" height="254" alt="image"
src="https://github.com/user-attachments/assets/a2831667-1113-49ac-b6aa-1221c71bf997"
/> | <img width="299" height="137" alt="image"
src="https://github.com/user-attachments/assets/ad6e85aa-ba24-47ad-b69d-6d0c3aa3a407"
/> |
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] 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
- [ ] Performance impact has been considered and is acceptable
Closes#57443.
Release Notes:
- Fixed Project Panel git status indicator showing modified files with a
warning color instead of the modified color
## Summary
Filenames containing md syntax (e.g. `__somefile__`, `*somefile*`) were
being rendered as markdown text in the file deletion confirmation
dialog.
Fixes#55651
## Changes
Wrapped file paths with `MarkdownEscaped` in the single and multi-file
deletion confirmation dialogs in `project_panel.rs`, so special md chars
like `_`, `*`, and `[` are escaped before being rendered.
## Testing
Created a file named `__somefile__` and tried to delete it, the name now
displays literally in the confirmation dialog instead of being rendered
as bold text:
<img width="339" height="206" alt="img"
src="https://github.com/user-attachments/assets/93e4e7d1-d5dc-45bb-9c08-2fe83c75aad2"
/>
Also added `test_delete_prompt_escapes_markdown_in_file_name` in
`project_panel_tests.rs` that verifies filenames with markdown special
characters render literally in the confirmation dialog.
Release Notes:
- Fixed file names containing markdown special characters (e.g.
`__somefile__`)
being rendered as formatted text in the file deletion confirmation
dialog.
Allows using the "View history" functionality also on folders and the
project root, and not only on files.
Renamed "View file history" to "View history" in the context menu to
make it consistent.
<img width="1740" height="769" alt="project_history"
src="https://github.com/user-attachments/assets/7f7f8115-6160-44f5-868f-69ac942df8e4"
/>
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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added git history for folders and whole project
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
## Summary
This PR replaces the git file history view with the git graph view that
doesn't render the graph canvas. This has several advantages
1. Benefits from the graphs performance and lazy loading
2. Gets the graph's search for free
3. Resizable columns
4. The commit information panel
5. Is persistent
6. Cleans up a lot of code
The one con of this change is the graph doesn't have support
remote/collab support yet, but that is a WIP and should be merged within
a week.
Also, the git graph now propagates errors to the UI, which is the last
thing on the graph's stable launch todo list!
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:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Joseph T. Lyons <JosephTLyons@gmail.com>
This PR adds a "Add to .gitignore" action to the project panel's
right-click context menu. Similar to the "Restore File" action that I
previously added, I frequently find myself wanting this in the project
panel.
<img width="380" height="391" alt="image"
src="https://github.com/user-attachments/assets/e4438fbe-b070-40c8-9e57-84b003fa5c15"
/>
With the restore file option:
<img width="382" height="408" alt="image"
src="https://github.com/user-attachments/assets/84425de8-04e5-4969-8991-edc46e6420dc"
/>
Notes:
- **Implementation**: The `add_to_gitignore` function is essentially
copy-pasted from `git_panel.rs`.
- **Error handling**: Added toast notification on error, which is
consistent with `restore_file` in project_panel and `perform_checkout`
in git_panel.
Note that `add_to_gitignore` in git_panel does NOT show a toast (just
uses `detach_and_log_err`). I don't know if this is on purpose.
To follow up, I can either: match the project_panel implementation to
the git_panel one (no toast), or update the git_panel implementation to
also show a toast on error.
- **Menu grouping**: Previously "Restore File" and "View File History"
were in separate sections, but both relate to git. With this third git
action, I grouped all three together under a single separator (see
screenshot).
We could also keep "View File History" separate and only group "Restore
File" + "Add to .gitignore" together (both modify the working tree state
in some way), if we don't want to alter the existing UI too much.
Release Notes:
- Added "Add to .gitignore" option to the project panel context menu for
files in git repositories.
---------
Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com>
This fixes#53869.
Creating a new file from the project panel background menu failed when a
single local project was empty and its root was hidden. In that state
there are no visible entries to seed `expanded_dir_ids`, so the action
returned early before opening the filename editor.
This initializes that state lazily from the root entry when creating a
new item, and adds a regression test for the empty hidden-root path.
Release Notes:
- Fixed creating a new file from the project panel context menu in empty
local projects
