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#53604.
When `log.showSignature = true`, git prepends signature verification
lines to stdout before the `--format` output. The null-separated parsers
in `crates/git/src/repository.rs` weren't expecting that, so SHAs ended
up corrupted — the git graph detail panel showed "0 changed files" for
every commit, and file history was similarly broken.
Setting `-c log.showSignature=false` in `build_command` is the same
trick we already use for `core.fsmonitor`. It only affects
log/show/whatchanged, so other commands aren't touched.
Verified locally with an SSH-signed repo: before this change the detail
panel said "0 changed files"; after, the modified files show up
correctly.
Release Notes:
- git_graph: Fix breakage that occurs when `log.showSignature` is
enabled
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
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.
## Summary
Fixes the `git: worktree` popup showing no worktrees when a project is
opened at the parent of a `.bare` directory (the common
bare-clone-with-sibling-worktrees layout).
## What's fixed
- `crates/git/src/repository.rs`
- New `git_binary_for_worktree_list` helper that uses
`repository.path()` as the working directory when `workdir()` is `None`.
- `worktrees()` switched to the new helper.
- `parse_worktrees_from_str` accepts bare entries without a `HEAD` line.
- Tests
- Unit test: parser handles a bare entry with no `HEAD` followed by a
normal worktree entry.
- Integration test: full `.git`-file → `.bare` + sibling worktrees
layout (`main`, `feature-a`, `feature-b`) is listed correctly via the
real `git` binary.
UI rendering already gates on empty sha (`worktree_picker.rs` uses
`.when(!sha.is_empty(), ...)`), so the bare entry's empty sha renders
without artifacts.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments — N/A, no `unsafe`
- [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 — same
single `git worktree list --porcelain` invocation, no extra work
#### Closes#54824
Video
[Screencast from 2026-04-28
09-43-45.webm](https://github.com/user-attachments/assets/e414d546-eb61-4cb2-857e-3c392f416f96)
Release Notes:
- Fixed the `git: worktree` popup listing no worktrees when a project
was opened at the parent of a `.bare` directory
(bare-clone-with-sibling-worktrees layout).
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
* Perform grouping even for repositories that have no main worktree
* Enable grouping for remote projects
* Delete entire project groups when deleting via the recent project
picker
Release Notes:
- Fixed a bug where each linked worktree appeared as its own entry in
recent projects for repositories without main worktrees
- Fixed a bug where deleting projects from the recent projects sometimes
appeared to have no effect.
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>
Fixes https://github.com/zed-industries/zed/issues/54830
This fixes a bugs where
* when there's no main worktree, we treated the first linked worktree as
main
* the titlebar and sidebar showed two different things when opening a
linked wortree directly
When there's no main worktree, our "project group key" will be the bare
repo path. For displaying this to the user, we try to present something
meaningful:
* If the bare repo is `foo.git`, we'll say "foo"
* If the bare repo is "bar/.bare", we'll "bar"
Release Notes:
- Fixed bugs in Zed's sidebar and titlebar when editing in git worktrees
created from bare repositories.
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
Using the existing commit editor in the Git Panel to type out longer
commit messages has been somewhat hard. I believe this happens because
it takes a very small portion of the UI which, unfortunately, when `git:
expand commit editor` is used, a modal ends up taking the center of the
editor, making it possible to have the commit editor open on the side,
while the `git: diff` view is open.
As such, this Pull Request introduces a new
`git::ToggleFillCommitEditor` action that allows users to update the
commit editor's height so as to take as much vertical space as possible,
hiding the entries status and simply rendering the Git Panel's footer.
This makes it easier to be able to write longer commit messages while
still having the `git: branch diff` on the side, something that's very
complicated with the default number of lines in the commit editor and
impossible using the `CommitModal`.
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:
- Added a `git::ToggleFillCommitEditor` action that expands the commit
editor to fill the git panel's available vertical space.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Danilo Leal <67129314+danilo-leal@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>
I frequently use the branch name copy action in GitHub Desktop.
I want to do this in Zed.
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 a `git: copy branch name` action.
### 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>
adds a 'git: view commit' – accepting a ref (e.g. HEAD, an sha, etc) to
more easily navigate to the git commit view.
<img width="3024" height="1888" alt="Screenshot 2025-09-26 at 21 43
09@2x"
src="https://github.com/user-attachments/assets/c001baec-66c2-46e5-b4a7-f691631f4166"
/>
if a bad ref is entered, the user is shown a generic error
<img width="2734" height="1442" alt="Screenshot 2025-09-27 at 21 04
52@2x"
src="https://github.com/user-attachments/assets/abdbd92d-ef0b-4de9-afb9-e9e52607dfdd"
/>
happy to adjust any of that. also worth noting is the `git: branch`
command UI is a bit nicer, can e.g. show you some metadata on the commit
before you select it, so happy to take it further in that direction if
desired, but thought i'd keep it simple to start.
Release Notes:
- Added view commit command palette action
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
- Don't ever swap to the ellipsis menu with the close icon button; we
now always have it
- Promote the "focus the last workspace" feature through the ellipsis
menu
- Add a unified tooltip for the thread item to show relevant thread
metadata
- Use a different icon for accessing the now "all threads" view
- Simplifies how we display archived threads
- Bonus: Don't display the "open in new window" button in currently
active worktrees (in dedicated picker)
- Bonus: Use the "main worktree" label for whenever we're mentioning the
original worktree
Release Notes:
- N/A
### 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
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>
## Context
When using a bare-repo-based git worktree layout (e.g. `foo/.bare` as
the bare repository and `foo/my-feature` as a linked worktree), the
"recent projects" modal was showing `foo/.bare` instead of
`foo/my-feature`.
The root cause was in `original_repo_path_from_common_dir` — when
resolving a linked worktree back to its "main" repo, the function reads
the `commondir` file which, for bare repos, points to the bare directory
itself (e.g. `foo/.bare`). Since that path doesn't end in `.git`, the
old code fell back to returning it as-is. This bare repo path was then
substituted into the workspace's stored paths, causing the modal to show
the bare directory instead of the actual worktree the user had opened.
The fix makes `original_repo_path_from_common_dir` return
`Option<PathBuf>`, returning `None` when `common_dir` doesn't end with
`.git`. `resolve_git_worktree_to_main_repo` propagates this `None`,
meaning the original worktree path is preserved in recent projects
rather than being replaced with the bare repo path.
Closes#52931
Video of the manual test after the fix is below :
[Screencast from 2026-04-02
16-05-48.webm](https://github.com/user-attachments/assets/9659c7a7-c095-4c23-af59-17715f84ce3e)
## How to Review
- **`crates/git/src/repository.rs`** :
`original_repo_path_from_common_dir` changed to return
`Option<PathBuf>`. Returns `None` for bare repos (no `.git` suffix). The
existing `original_repo_path` call site falls back to `work_directory`
when `None` is returned, preserving its prior behaviour. Unit test
expectations updated accordingly, with the bare-repo case now asserting
`None`.
- **`crates/project/src/git_store.rs`** :
`resolve_git_worktree_to_main_repo` now simply forwards the
`Option<PathBuf>` returned by `original_repo_path_from_common_dir`
directly, propagating `None` for bare repos so the caller keeps the
original worktree path.
- **`crates/workspace/src/persistence.rs`** : New test
`test_resolve_worktree_workspaces_bare_repo` exercises the exact
scenario from the issue: a workspace entry pointing to a linked worktree
whose `commondir` resolves to a bare repo. Asserts the path is left
unchanged.
## 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
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed recent projects modal showing `.bare` folder instead of the
worktree directory for bare-repo-based git worktree setups
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>
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>
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>
For submodules, `common_dir_abs_path` equals `repository_dir_abs_path`
(since submodules don't have a `commondir` file). The previous code
passed this path to `original_repo_path_from_common_dir`
unconditionally, which returned the `.git/modules/<name>` path as the
`original_repo_abs_path` — causing `linked_worktree_path()` to return a
false positive for submodules.
Now we detect linked worktrees by checking whether `common_dir` differs
from `repository_dir` (only true for actual linked worktrees that have a
`commondir` file). For normal repos and submodules,
`original_repo_abs_path` is simply `work_directory_abs_path`.
Also fixes the misleading doc comment on `common_dir_abs_path` in
`LocalRepositoryEntry` and adds test assertions for
`original_repo_abs_path` and `linked_worktree_path()` on both worktrees
and submodules.
Closes AI-102
Release Notes:
- Fixed git submodules being incorrectly classified as linked worktrees,
which could cause issues with worktree-related operations.
## 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
## Summary
Zed's git checkpoint code was assuming that repository-local metadata
always lives under `<working-directory>/.git/...`.
That assumption breaks for repositories where `.git` is a file instead
of a directory, most notably:
- git submodules
- git worktrees
In those layouts, `.git` contains a `gitdir: ...` pointer to the real
git directory. When checkpoint creation or restore tries to build paths
like `.git/index-<uuid>.tmp` or `.git/info/exclude`, those path
operations fail with `Not a directory (os error 20)`.
In practice, that shows up as checkpoint failures in ACP threads for
worktrees and submodules.
## Root Cause
`GitBinary` tracked the repository working directory, but it did not
track the resolved git directory.
As a result, checkpoint-related helpers derived temporary index and
exclude paths from the working tree:
- temp index path creation
- copying the default index into the temp index
- exclude override handling
That works for a plain repository where `.git` is a directory, but not
when `.git` is a pointer file.
## Changes
- Thread the resolved git directory from `RealGitRepository::path()`
into `GitBinary`.
- Add a dedicated `git_directory` field to `GitBinary`.
- Use `git_directory` instead of `<working-directory>/.git` for:
- temp index file paths
- copying the default `index`
- `info/exclude` override paths
- Keep the working directory unchanged for command execution; only
metadata path resolution changes.
- Add a regression test that verifies temp index files are created under
the real gitdir, not under `<working-directory>/.git`.
## Why this approach
The minimal correct fix is to distinguish between:
- the working directory used to run git commands, and
- the actual git directory used to store repository metadata
Git itself already makes that distinction, and
`git2::Repository::path()` gives us the resolved gitdir directly.
Reusing that value keeps the fix small and avoids special-casing
submodules or worktrees elsewhere.
## User-visible impact
Before this change, checkpoint operations could fail in repositories
where `.git` is not a directory, producing errors like:
Not a directory (os error 20)
After this change, checkpoint-related git metadata is read and written
from the real gitdir, so ACP checkpoints work in submodules and
worktrees the same way they do in regular repositories.
## Testing
- `cargo fmt -p git`
- `cargo test -p git --lib`
- `cargo clippy -p git --lib --tests -- -D warnings`
Added regression coverage:
- `test_path_for_index_id_uses_real_git_directory`
If you want, I can also compress this into a more GitHub-PR-native
version with sections like `## Problem`, `## Fix`, and `## Validation`.
Release Notes
- Fixed `.git` handling when `.git` is a file instead of directory, e.g.
when using worktrees or submodules.
* [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>
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
When on a untrusted project, if one was to try and use the commit
generation functionality, the command would fail because of the `-c
diff.external` configuration provided in `GitBinary::build_command`, as
git would interpret this as `""` and try to run that command.
This `-c diff.external` is a good safeguard to have on untrusted
repositories because it prevents random commands, configured in
`.git/config` from being run. For example, if one uses `git config
diff.external "touch bananas.txt"` and then run `git diff`, a new
`bananas.txt` file would be created.
However, it was still possible to bypass this safeguard using the
following strategy:
1. Specify a custom diff for a specific file format. For example, for
markdown files, with `printf '*.md diff=pwned\n' > .gitattributes`
2. Update the command run by the `pwned` diff, for example, `git config
diff.pwned.command "touch bananas.txt"`
3. Open Zed and attempt to generate a commit message in an untrusted
repository and check that a new `bananas.txt` file was created
This is only prevented by using the `--no-ext-diff` flag on the `diff`
command, so a new `GitBinary::build_diff_command` has been introduced
which simply wraps `GitBinary::build_command` and adds the
`--no-ext-diff` flag, if necessary.
As a side-effect, this also makes it so that generating a commit message
in an untrusted repository works again, which was accidentally broken on
https://github.com/zed-industries/zed/pull/50649 .
Before you mark this PR as ready for review, make sure that you have:
- [X] Added a solid test coverage and/or screenshots from doing manual
testing
- [X] Done a self-review taking into account security and performance
aspects
- [X] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Fixed commit message generation in untrusted repositories
This will help with test times (in some cases), as nextest cannot figure
out whether a given rdep is actually an alive edge of the build graph
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
Add a `git::RestoreAndNext` action that restores the diff hunk at the
cursor and advances to the next hunk. In the git diff view, the default
restore keybinding (`cmd-alt-z` on macOS, `ctrl-k ctrl-r` on
Linux/Windows) is remapped to this action so users can quickly restore
hunks in sequence. Also refactor `go_to_hunk_before_or_after_position`
to accept a `wrap_around` parameter, eliminating duplicated
hunk-navigation logic in `do_stage_or_unstage_and_next` and
`restore_and_next`.
Release Notes:
- Added a `git: restore and next` action that restores the diff hunk at
the cursor and moves to the next one. In the git diff view, the
default restore keybinding (`cmd-alt-z` on macOS, `ctrl-k ctrl-r` on
Linux/Windows) now triggers this action instead of `git: restore`.
---------
Co-authored-by: Afonso <4775087+afonsograca@users.noreply.github.com>
follow up on: https://github.com/zed-industries/zed/pull/50649
When committing in a restrictive workspace we avoid running git hooks
instead of failing the commit because hooks aren't allowed. I also
passed in more git cli hardening configurations to use when Zed spawns
git commands
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:
- N/A
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
We were trying to mitigate these by passing `.` instead of ``, but it
turns out that git2 also panics internally for that. It also just
doesn't make sense to look up the index text (or committed text) for an
empty path, because a file should always have a nonempty repo path.
Closes ZED-560
Release Notes:
- N/A
This PR adds the small UI change of `git diff --numstat` to the git
panel so you can see the number of additions/deletions per file. There
is an option in the settings UI for this under `git_panel`.`diff_stats`.
This option is set to `false` by default.
<!-- initial version <img width="1648" height="977" alt="Screenshot
2026-02-18 at 18 42 47"
src="https://github.com/user-attachments/assets/b8b7f07c-9c73-4d06-9734-8f1cf30ce296"
/> -->
<img width="1648" height="977" alt="Screenshot 2026-02-18 at 21 25 02"
src="https://github.com/user-attachments/assets/73257854-6168-4d12-84f8-27c9e0abe89f"
/>
Release Notes:
- Added git diff stats to git panel entries
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Anthony Eid <anthony@zed.dev>
## Summary
Fixes **ZED-2XA** — "Unexpected duplicated status entries: Untracked and
Untracked" crash.
**Impact:** 22 occurrences, 3 users affected (Sentry). The panic was
introduced in #23483 (2025-01-22) which added the `dedup_by` logic for
handling deleted-in-index + untracked file combinations.
No related GitHub issues were found filed against this crash.
## Root Cause
`GitStatus::from_str` sorts entries by path and then calls `dedup_by` to
merge duplicate entries. The only handled case was `(INDEX_DELETED,
Untracked)` — all other duplicates hit a catch-all `panic!`. In
practice, git can produce duplicate `??` (untracked) entries for the
same path, which triggered this crash.
## Fix
- Identical duplicate statuses (e.g., `Untracked, Untracked`) are now
silently deduplicated (keep one)
- Other unexpected duplicate combinations log a warning instead of
crashing
- Added a regression test that parses `"?? file.txt\0?? file.txt"` and
verifies it produces a single entry
## Verification
- Reproduction test passes: `cargo test -p git --
test_duplicate_untracked_entries`
- Full crate tests pass: `cargo test -p git` (20/20)
- Clippy clean: `./script/clippy`
Release Notes:
- Fixed a crash when git produces duplicate status entries for the same
file path
Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
The AI-assisted "Review Diff" action was only working for committed
changes because we were passing HEAD in the git command. Without it, it
captures all of the working tree changes, the same way the Branch Diff
view itself does. I think this is now better and more intuitive, because
it shouldn't be required that you commit the changes to have them
quickly reviewed by an agent.
Release Notes:
- N/A
