Technically we don't know if a `virtiofs` file system supports `inotify`
or not, but it seems like it's mostly used inside virtual machines
provided by:
- OrbStack (`inotify` works)
- Docker Desktop (`inotify` works)
- Lima (`inotify` works with flag)
- Colima (`inotify` works with flag)
- QEMU + virtiofs setup (`inotify` doesn't work without extra setup)
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#57103
Closes FR-9
Release Notes:
- Fixed an issue where file system watching would default to the polling
backend inside of `OrbStack` VMs on MacOS
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
Closes #ISSUE
Part of FR-9.
Release Notes:
- N/A or Added/Fixed/Improved ...
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>
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 https://github.com/zed-industries/zed/issues/55746
Release Notes:
- Fixed an issue where file system events or language server events that
resulted in Zed unwatching many paths would result in high CPU usage
Follows similar approach as
https://github.com/zed-industries/zed/pull/55927
Adds a force-delete path to the worktree picker. Normal delete now
prompts when Git reports modified or untracked files, and
Alt/Option-delete can force delete directly.
Release Notes:
- Added support for force deleting worktrees that contain modified or
untracked files.
Git's `-d` flag deletes a branch only if it's fully merged into its
upstream or HEAD - this is what we were using before, which caused the
"not fully merged" error. The `-D` flag force deletes a branch even with
unmerged changes (equivalent to `--delete --force`).
### Before
Deleting an unmerged branch failed with a "not fully merged" error
toast.
### After
- Deleting an unmerged branch prompts for confirmation to force delete
- Delete button tooltip shows "Hold alt to force delete" hint
- Holding **alt** turns the delete icon red and tooltip changes to
"Force Delete Branch"
- Force delete keybinding: `cmd-alt-shift-backspace`
Release Notes:
- Added confirmation prompt when deleting unmerged git branches, with
option to force delete.
- Added alt+click on delete button to force delete a branch immediately.
In #54481, the `handle_event` function was altered to check for an
`Access` event after the callbacks were acquired via a global state
lock. The lock/Vec-collect has enough overhead (or maybe there's enough
lock contention?) that the handler isn't performant enough to keep up
with the volume of inotify events, and its queue fills up, resulting in
[a rescan event getting
emitted](79007aefb4/notify/src/inotify.rs (L304-L306)),
which presumably results in *more* access events for the file as it's
rescanned, which further serve to fill up the inotify queue.
Moving the check for an `Access` event and returning before doing
anything remotely expensive seems to resolve the issues I've been having
lately. Not sure if it addresses the original issue in #53480 though.
Longer-term, it might be prudent to do the event handler's heavy-lifting
in a separate thread with its own event queue, and let the handler
passed to the `notify` crate be just a dumb `tx` sender.
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
Related to #53480Fixes#55829
Release Notes:
- Fixed inotify event queue overflows on linux
### Motivation
This is the second of three PRs to add remote/collab support for the git
graph and is a follow-up to #54468. I'm adding remote support for the
search because it's not user accessible without the initial graph fetch
having remote support, so it allows us to merge this without having to
add full remote support. Collab guest support will be added in a
follow-up PR.
#### Summary
For large repos, searching can take a while to fully stream in all
matched results. For example, running a basic search on the Linux repo
took over 10s for me. Because of that, we want to stream search results
in chunks to downstream users to keep the time-to-first-match low. After
this change, the first chunk gets sent back after ~50ms on the Linux
repo from receiving the request.
In order to accomplish that, I added a new proto client API that allows
for a request to map to n responses. e.g.
```/dev/null/example.rs#L1-1
client.add_entity_stream_request_handler(Self::handle_search_commits);
```
Note: The proto API isn't supported over collab yet, that will be
another PR
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
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
These changes update Zed's Git Panel to be able to detect unsafe git
repositories, where the user running Zed doesn't own the `.git`
directory, and show a dedicated empty view in the Git Panel that not
only explains the situation but also allows the user to choose whether
to trust this directory, which will end up running `git config --global
--add safe.directory <path>`.
While testing those changes, it was noted that attempting to add or
reset files after trusting the directory would fail, as expected, but
the UI wouldn't react to the fact that those operations failed. What
this means is, if the user tried to add a file, the UI would show a
checkmark for that file and, after the operation failed, the checkmark
would remain. We now revert that, for both `git add` and `git reset`.
Some more technical notes on this change:
- Introduce `project::git_store::GitAccess` enum to express whether we
actually have access to the repository, exposed via
`git::Repository::access`, which probes the backend with a `git status`
command and classifies the result.
- On unsafe repositories,
`project::git_store::LocalRepositoryState::new` fails to spawn the git
worker, which now cleanly signals `GitAccess::No` rather than leaving
the panel in a broken state.
- Updated `git_ui::git_panel::GitPanel::render_empty_state` with a third
alternative, when `GitAccess::No`, that basically renders a view
explaining why the repository is considered unsafe, together with
buttons for git's documentation on safe directories and a button to add
the repository's folder as a safe directory
- Updated `project::git_store::GitStore` to now watch `~/.gitconfig` and
`$XDG_CONFIG_HOME/git/config`. Watching this files allows the Git Panel
to react when the git configuration is updated, which will be the case
if the user decides to trust the repository. When either changes, a
`GitStoreEvent::GlobalConfigurationUpdated` event is emitted and the
panel refetches repository state.
- Added `project::git_store::Repository::refetch_repo_state` field,
which stores a closure to allow recreating the
`Repository::repository_state` and the job sender after the repository's
directory is trusted, without requiring a project reload.
- Added a `fs::Fs::git_config` trait method, wrapping a real `git
config` invocation. In order to be able to call this, both
`git_store::GitStore::git_config` and `project::Project::git_config`
wrappers have also been introduced. Worth mentioning that this isn't yet
supported for remote projects or collab guests.
- Updated `fs::Fs::git_clone` argument order to match
`fs::Fs::git_config` and `fs::Fs::git_init`.
- Added a new
`project::git_store::pending_op::PendingOps::last_op_errored` method
that allows determining whether the last pending operation failed. This
now allows us to filter out failed operations when determining whether
`git add` or `git reset` failed, so that we can fall through to the real
git status.
- Updated `git_ui::git_panel::GitPanel::change_file_stage` to now call
`update_counts` in its error branch so the cached staged counters stay
consistent with the reverted per-entry state, seeing as we now handle
reverting the UI state if an operation fails.
- Fixed `fs::RealFs::git_init` to fall back to the provided branch name
when `git config --global --get init.defaultBranch` fails, for example,
when the user hsan't configured one.
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Closes#42286
Release Notes:
- Added a dedicated empty state in the Git Panel for unsafe
repositories, with a "Trust Directory" button that adds the repository
to `safe.directory`
- Fixed stage and unstage checkboxes in the Git Panel not reverting when
a `git add` or `git reset` command failed
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
## 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>
No, sadly, the title is not a typo. See
https://www.githubstatus.com/incidents/zsg1lk7w13cf for the context.
I'll read with joy and popcorn through that root cause analysis.
It makes literally zero sense what happened here, but for some completly
bonkers reason GitHub completely messed up the merge queue with
https://github.com/zed-industries/zed/pull/54632.
I have no idea how it happened. It makes literally zero sense. A PR
going into the merge queue should have the same LoC when getting out of
it. GitHub obviously does not check this. GitHub causes extra work with
a feature that is supposed to save time.
Thanks, I guess.
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This PR brings back the button to filter remote branches when accessing
the title bar's branch picker with the mouse. It was unintentionally
removed when we introduced the new worktree picker.
Release Notes:
- N/A
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 ...
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
Closes#51340
Release Notes:
- Linux/WSL: Added polling filesystem watching support in order to
support file watching on file systems that do emit events through
`inotify`, for example `/mnt/c` in WSL, network filesystems, and FUSE
mounts. Polling should be automatically chosen over `inotify` when
necessary, however it can be manually chosen by setting the
`ZED_FILE_WATCHER_MODE=poll` env var
---------
Co-authored-by: Lilith River <lilith@imazen.io>
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
### Motivation
To support remote Git graph usage, we need remote support for the Git
APIs that the graph depends on. This PR adds remote support for
`CommitDataHandler` (the `git cat-file --batch` process manager),
allowing remote Git graph consumers to fetch visible commit data without
polling.
#### Summary
The Git graph separates the UI and data layers so the UI can continue
rendering while commit data is fetched in the background. This change
extends that model to remote repositories by allowing
`GitStore::fetch_commit_data(sha: Oid, await_result: bool, cx: &mut
Context) -> &CommitDataState` to await remote commit loading.
For simplicity, the `Starting` variant was removed from
`CommitDataState`. `CommitDataState::Loading(Option<...>)` now stores
`Some(...)` when `await_result == true` is passed to
`fetch_commit_data`. This allows the data layer to await commit loading
without polling, and only when explicitly requested.
I also removed the `Graph` prefix from `CommitData`-related types
because this API is general-purpose and not limited to the graph. Longer
term, I hope to replace `Repository::show` with the commit data
functionality, since it already provides built-in caching.
#### Bug Fixes
- Fix stale `Loading(...)` entries that survive enqueue failure or
handler shutdown.
- Fix commit data handler bookkeeping so `pending_requests`,
`completion_senders`, and `CommitDataState` remain consistent.
- Fix remote commit-data loading so the data layer can await results
instead of polling.
#### Testing
- Add property tests for commit data fetching.
- Add a collab integration test that verifies batched remote commit-data
fetching.
#### Follow Up
In a follow-up, I want to replace the `Repository::show` backend with
the commit data handler and remove `CommitDetails` from the codebase as
a cleanup and maintenance pass. The commit data handler already provides
caching and is a better long-term path for commit metadata access.
I may also want to allow the `CommitData` type to propagate errors to
callers.
For the Git graph, the remaining work is remote search and initial data
fetching.
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: Remco Smits <djsmits12@gmail.com>
### Summary
This PR implements remote support for git store operations that the
sidebar's archive thread checkpoint/restore featured relied on. This was
the second to last blocker for remote usage of this feature.
I also made a shared backend between `update_ref` and `delete_ref`
called `edit_ref` because they run the same git command and this allowed
for some code unification.
#### Remote Git Operations
- `Repository::update_ref`
- `Repository::delete_ref`
- `Repository::repair_worktrees`
- `Repository::create_archive_checkpoint`
- `Repository::restore_archive_checkpoint`
#### Follow up
`agent_ui::thread_worktree_archive::find_or_create_repository` needs to
be made aware of the remote machine that the repository it's searching
for is on. Once that is completed, we can get the correct repo when
archiving a remote thread and the flow should work without any problems.
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
When archiving a thread's linked worktree, `git worktree remove` can
fail to delete the working directory while still removing the admin
metadata in `.git/worktrees/<name>`. This leaves an orphaned folder on
disk that no longer appears in `git worktree list`.
## Fix
Delete the directory ourselves first with `std::fs::remove_dir_all`,
then call `git worktree remove --force` to clean up only the admin
entry. Git already handles the case where the working tree is already
gone (since
[git/git@ee6763a](ee6763af0a)).
Also fixes `FakeGitRepository::remove_worktree` to handle a missing
working tree directory (matching real git behavior) by scanning
`.git/worktrees/` entries when the `.git` pointer file can't be read.
Release Notes:
- Fixed archiving an agent thread sometimes leaving the worktree folder
on disk even though the git worktree was removed.
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>
Create worktrees in detached HEAD state, then attempt to check out the
requested branch. If the checkout fails (e.g. the branch is already in
use by another worktree), log a warning and stay in detached HEAD state
instead of showing an error to the user.
This simplifies the worktree creation flow by:
- Removing the occupied-branch fallback logic that would generate random
branch names
- Always using `CreateWorktreeTarget::Detached` for worktree creation
- Attempting branch checkout as a best-effort post-creation step
- Updating the branch picker UI to reflect the new behavior
Release Notes:
- Threads now start git worktrees in detached HEAD state if branch is in
use or unspecified, instead of generating a random branch name.
---------
Co-authored-by: Eric Holk <eric@zed.dev>
- 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>
Update both `Fs::trash_dir` and `Fs::trash_file` to now return the
location of the trashed directory or file, as well as adding the
`trash-rs` create dependency and updating the `RealFs` implementation
for these methods to simply leverage `trash::delete_with_info`.
* Add `fs::Fs::TrashedEntry` struct, which allows us to track the
original file path and the new path in the OS' trash
* Update the `fs::Fs::trash_dir` and `fs::Fs::trash_file` signatures to
now return `Result<TrashedEntry>` instead of `Result<()>`
* The `options` argument was removed because it was never used by
implementations other than the default one, and with this change to
the signature type, we no longer have a default implementation, so the
`options` argument would no longer make sense
* Update `fs::RealFs::trash_dir` and `fs::RealFs::trash_file`
implementations to simply delegate to `trash-rs` and convert the
result to a `TrashedEntry`
* Add `fs::FakeFs::trash` so we can simulate the OS' trash during tests
that touch the filesystem
* Add `fs::FakeFs::trash_file` implementation to leverage
`fs::FakeFs::trash`
* Add `fs::FakeFs::trash_dir` implementation to leverage
`fs::FakeFs::trash`
Don't move the branch when making WIP commits during archiving; instead
make detached commits via `write-tree` + `commit-tree`.
(No release notes because this isn't stable yet.)
Release Notes:
- N/A
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
Connect the git API and archived worktree data model to the sidebar's
archive/unarchive flow:
- Add `thread_worktree_archive` module: orchestrates the full archive
cycle (WIP commits, DB records, git refs, worktree deletion) and restore
cycle (detached worktree creation, reset to recover staged/unstaged
state, branch restoration)
- Integrate into sidebar: `archive_thread` now persists worktree state
before cleanup; `activate_archived_thread` restores worktrees via git
with targeted path replacement for multi-root threads
- Add pending worktree restore UI state with spinner and cancel button
- Show toast on restore failure instead of silent log
- Switch to surviving workspace when archiving active thread whose
workspace will be deleted
- Deserialize persisted `project_group_keys` on window restore
- Guard `cleanup_empty_workspaces` against dropped entities
- Await rollback DB operations instead of fire-and-forget
Part 3 of 3 in the persist-worktree stack. Stacked on #53214. This wires
up parts 1 and 2.
Release Notes:
- Added worktree state preservation when archiving agent threads,
automatically restoring staged and unstaged changes when the thread is
unarchived
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
Based on commit fba49809b3 that I worked
with Dino on in PR: #50288
Co-authored-by Dino \<Dino@zed.dev\>
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 ...
This PR allows users to create a new thread based off a git worktree
that already exists or has a custom name. User's can also choose what
branch they want the newly generated worktree to be based off of.
The UI still needs some polish, but I'm merging this early to get the
team using this before our preview launch. I'll be active today and
tomorrow before launch to fix any nits we have with the UI.
Functionality of this feature works! And I have a basic test to prevent
regressions
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 ...
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Extend the git API with several new capabilities needed for worktree
archival and restoration:
- Add `allow_empty` flag to `CommitOptions` for creating WIP marker
commits
- Change `create_worktree` to accept `Option<String>` branch, enabling
detached worktree creation when `None` is passed
- Add `head_sha()` to read the current HEAD commit hash
- Add `update_ref()` and `delete_ref()` for managing git references
- Add `stage_all_including_untracked()` to stage everything before a WIP
commit
- Implement all new operations in `FakeGitRepository` with functional
commit history tracking, reset support, and ref management
- Update existing call sites for the new `CommitOptions` field and
`create_worktree` signature
Part 1 of 3 in the persist-worktree stack. These are nonbreaking API
additions with no behavioral changes to existing code.
Release Notes:
- N/A
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
### Summary
This PR fixes an issue where the git graph wouldn't refresh its state
correctly unless HEAD changed. Now repository emits events when the
branch list has changed, and invalidates the graph data cache when the
stash or branch list has changed.
I also renamed the event `Repository::BranchedChanged` to
`Repository::HeadChanged` as well.
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#53080
Release Notes:
- N/A or Added/Fixed/Improved ...
Closes#47907
Implements the four git checkpoint operations (`create`, `restore`,
`compare`, `diff`) that had been stubbed out for remote repositories,
and related test infrastructure.
Testing steps:
1. Open a project with a `.devcontainer` configuration and connect to
the Dev Container
2. Open an Agent thread and ask the agent to make a code change
3. After the agent completes, verify the "Restore from checkpoint"
button appears (previously missing in Dev Container sessions)
4. Click "Restore from checkpoint" and confirm the file reverts to its
prior state
Release Notes:
- Added support for git checkpoint operations in remote/Dev Container
sessions, restoring the "Restore from checkpoint" button in Agent
threads.
---------
Co-authored-by: KyleBarton <kjb@initialcapacity.io>
This operation would always fail in the UI because the git binary
already disallowed it. This PR just makes the UI more inline with what's
actually valid
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:
- git: Forbid main git worktree deletion from git worktree picker
---------
Co-authored-by: Eric Holk <eric@zed.dev>
## Context
This uses `git log` to get a basic search working in the git graph. This
is one of the last blockers until a full release, the others being
improvements to the graph canvas UI.
## Self-Review Checklist
<!-- Check before requesting review: -->
- [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: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
When a git worktree is in a detached HEAD state (e.g. after `git
checkout --detach`), the workspace for that worktree would disappear
from the sidebar UI, and if the workspace was currently open your UI
would just disappear.
This happened because `parse_worktrees_from_str` silently dropped any
worktree entries without a `branch` line in the porcelain output, which
cascaded through the `linked_worktrees` list and caused
`prune_stale_worktree_workspaces` to remove the workspace.
This PR:
- Makes `Worktree::ref_name` an `Option<SharedString>` so detached
worktrees can be represented
- Renames `Worktree::branch()` to `Worktree::display_name()`, which
returns the branch name when available or the short SHA as a fallback
(mirroring how the title bar already handles detached HEAD for
repositories)
- Updates `parse_worktrees_from_str` to include detached and bare
worktree entries instead of dropping them
- Filters detached worktrees out of the worktree picker UI, preserving
the existing product decision to only show branch-based worktrees there
## 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
* [x] Display original project name as root folder in project panel,
titlebar
* [x] When manually creating worktrees, ensure final path component is
original project name
* [x] Display original project name, worktree name, and branch name in
titlebar
* [x] Only show main checkout in project switcher
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Fixes#51778
#### Fix
- Add `EINVAL` to the list of error codes that trigger the
metadata-based rename fallback in `crates/fs/src/fs.rs`
- FUSE filesystems (NTFS via ntfs-3g, exFAT, etc.) return `EINVAL` when
`renameat2` is called with `RENAME_NOREPLACE`, since they don't support
the flag.
- The existing fallback already handles `ENOSYS`, `ENOTSUP`, and
`EOPNOTSUPP` for similar unsupported-operation cases.
#### Video
[Screencast from 2026-03-17
23-37-35.webm](https://github.com/user-attachments/assets/77e35d97-a87c-4acf-99b8-0e74df667275)
Release Notes:
- Fixed file and directory renaming failing in the project panel on
FUSE-based filesystems (e.g. NTFS, exFAT drives on Linux).
While fixing the tests in the previous PR (#48338), I noticed that the
`delete_branch` tests only verified the UI state changes rather than the
actual state of the underlying repository.
Currently, if `delete_branch` were a no-op that returned Ok(), the tests
would still pass incorrectly. This PR addresses that gap by ensuring the
branch is actually removed from the repository.
|Before|After|
|--|--|
|<img width="3476" height="2564" alt="图片"
src="https://github.com/user-attachments/assets/f5c4c5c4-64fe-4074-9fff-fb166d160d77"
/>|<img width="3476" height="2564" alt="CleanShot 2026-03-18 at 17 51
36@2x"
src="https://github.com/user-attachments/assets/47419d37-5051-4139-969e-65a1347bf555"
/>|
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
- [ ] 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 ...
Closes#48256
It appears that the current git remotes support was implemented in
#42819, following the design described in
https://github.com/zed-industries/zed/pull/42486#issuecomment-3524092306.
That design does not include an interaction for deleting remotes, but
the delete remote branch action was mistakenly implemented as deleting
the remote itself.
After this PR, there should be no code paths that use `remove_remote`
anymore. I've kept it for now though, as it may be useful when we
introduce the corresponding interaction in the future.
Release Notes:
- Fixed a bug where deleting a remote branch from the branch picker
would incorrectly remove the entire remote configuration
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 ...
Closes#46307
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)
Release Notes:
- Improved compatibility with mounted VHDs on Windows.
---------
Co-authored-by: John Tur <john-tur@outlook.com>
Implements worktree support for the agent panel sidebar
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
Closes#46661
This PR changes `fs.rename` to use the platform’s atomic no-overwrite
rename on all platforms when `overwrite` is `false`. This fixes a case
where concurrent renames to the same target could race past a separate
metadata check and end up overwriting each other.
In Project Panel, we can still rename entries in parallel without
worrying about OS internals not handling it correctly or making these
renames sequential.
Release Notes:
- Fixed an issue in the Project Panel where conflicting file moves could
overwrite each other instead of leaving the losing file in place.
Follow up on: https://github.com/zed-industries/zed/pull/49519
This PR reworks how Zed calculates diff num stats by moving the
calculation to the `RepositorySnapshot` layer, instead of the
`GitPanel`. This has a couple of benefits:
1. Snapshot recalculations are already set up to recompute on file
system changes and only update the affected files. This means that diff
stats don't need to manage their own subscription or states anymore like
they did in the original PR.
2. We're able to further separate the data layer from the UI. Before,
the git panel owned all the subscriptions and tasks that refreshed the
diff stat, now the repository does, which is more inline with the code
base.
3. Integration tests are cleaner because `FakeRepository` can handle all
the data and calculations of diff stat and make it accessible to more
tests in the codebase. Because a lot of tests wouldn't initialize the
git panel when they used the git repository.
4. This made implementing remote/collab support for this feature
streamline. Remote clients wouldn't get the same buffer events as local
clients, so they wouldn't know that the diff stat state has been updated
and invalidate their data.
5. File system changes that happened outside of Zed now trigger the diff
stat refresh because we're using the `RepositorySnapshot`.
I added some integration tests as well to make sure collab support is
working this time. Finally, adding the initial diff calculation to
`compute_snapshot` didn't affect performance for me when checking
against chromium's diff with HEAD~1000. So this should be a safe change
to make.
I decided to add diff stats on the status entry struct because it made
updating changed paths and the collab database much simpler than having
two separate SumTrees. Also whenever the UI got a file's status it would
check its diff stat as well, so this change makes that code more
streamlined as well.
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.
Release Notes:
- N/A
This PR cleans up the git command spawning by wrapping everything in
GitBinary instead to follow a builder/factory pattern. It also extends
trusted workspace support to git commands.
I also added a `clippy.toml` configuration to our git crate that warns
against using `Command` struct to spawn git commands instead of going
through `GitBinary`. This should help us maintain the factory pattern in
the future
Before you mark this PR as ready for review, make sure that you have:
- [x] Added solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
Release Notes:
- git: Add trusted workspace support for Zed's git integration
The main issue is that we weren't forwarding the proto messages through
the collab server to the host. After fixing that I added integration
tests to cover local worktrees, remote worktrees, and ssh worktrees.
I also fixed a bug with FakeRepository where it wouldn't name its
current branch as a worktree when calling git worktree, which doesn't
match the behavior of the git binary.
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
Release Notes:
- git: Fix bug that caused the git worktree picker from displaying and
creating worktrees over collab
