While building Zed with nightly rustc I've noticed it doesn't compile
because of good old pathfinder_simd. It also emits a bunch of warnings
about use of f64 literals where f32 is expected, so I've fixed them - it
should make future upgrades more straightforward.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments (N/A)
- [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
I was unable to find an issue or PR which mentions this.
Extensions with non-GitHub repository links always use the GitHub icon,
which is inconsistent with the changes merged in #44738 and #57500. This
change makes `extension_ui.rs` use the Git hosting provider registry to
determine these icons. Below is a preview of the change:
<div align="center">
<img
width="450"
alt="Preview"
src="https://github.com/user-attachments/assets/e35f0eed-de54-48f9-824d-8a5b9bfc596f"
/>
</div>
Release Notes:
- Improved extension repository links to show provider-specific icons.
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 (5e1fd392f6): 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
This PR explores the addition of a new feature and UI to improve
visibility into partially staged commits.
Currently, the Git panel shows tracked and untracked changes, but it
does not clearly distinguish between staged and unstaged changes.
As a result, it’s difficult to quickly see which changes are not staged
in the current UI. Both staged and unstaged changes are combined into
the `Uncommitted Changes` multibuffer. This developer experience differs
from other editors, most notably VS Code; which presents separate Staged
Changes and Changes lists.
### Staged and unstaged diffs in multibuffers
This PR introduces an alternative UI for unstaged changes that aligns
with the overall Zed experience. Instead of showing changes on a
per-file basis, staged and unstaged diffs are each displayed in their
own multibuffers, similar to how `Uncommitted Changes` currently works.
For example the following screenshot shows the current `Uncommitted
Changes` on the left, the `Staged Changes` in the middle and the
`Unstaged Changes` buffer on the right for comparison
<img width="1408" height="859"
src="https://github.com/user-attachments/assets/aa709f7a-041d-4cb1-95d6-84c0f5fff688"
/>
### Indicators/interactions
The new multibuffers can be opened in two ways:
1. Via a new `U` chip, which appears when a file has unstaged changes
2. Via new menu options
(See screenshots below for both interaction paths.)
<table>
<tr>
<td style="text-align: center; vertical-align: top;">
<p>via the chip</p>
<img
height="400"
src="https://github.com/user-attachments/assets/3ef69f02-b787-499c-959a-25f50b3728e8"
alt="Via the chip"
/>
</td>
<td style="text-align: center; vertical-align: top;">
<p>via the menu</p>
<img
height="400"
src="https://github.com/user-attachments/assets/f5be8b6d-ccdc-4420-bd29-75570b558016"
alt="Via the menu"
/>
</td>
</tr>
</table>
### Design goals
- minimally intrusive UI changes (small new badge and menu items)
- adhere by Zed'ism (use multibuffer where possible)
- avoid disabling any current interactions (Uncommitted Changes ui is
unchanged)
- avoid introducing an app level view mode (no new settings needed)
### Experience goals
- make it easy to see what changes are not staged
- make it easy to see that a file has unstaged changes (avoid developers
accidently leaving out changes in a commit; a personal issue that I have
when using Zed)
- elegantly handle large file's unstaged changes (follows the same
collapse and expanding seen in `Uncommitted Changes`)
### How to try
- Clone the repo and run `cargo run`
- Make a change to a file and stage it
- Make another change to the file (the `U` indicator will appear)
- Click the `U` to see the unstaged view
### Open questions/rough edges
- [ ] determine if this user experience is useful for others
- [ ] ensure all interactions work as expected (response to all update
cases)
In general I'm really interested in hearing the community's feedback
about this interface, more than happy to make any changes or explore a
different solution!
### Related issue:
- https://github.com/zed-industries/zed/pull/36646
- https://github.com/zed-industries/zed/issues/26560
Release Notes:
- Support partially staged commit multibuffers via a staged and unstaged
changes view.
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Cole Miller <cole@zed.dev>
This PR adds a bunch of design improvements to the toolbar of (tab)
views that display diffs: the uncommitted changes, branch diff, and
agent diff tabs. This involves adjusting spacing, sizing, and other
small tweaks across all of these views, including touching up the
divider component API a little bit, adjusting Git icons design, adding
diff stat numbers to the uncommitted changes tab so its consistent with
the others, and more (e.g., moving the split buttons into its own
component to ensure they look the same across all uses). Ended up also
going on a slight de-tour to make all uses of the split button in the
Git panel consistent design-wise.
All in all, this is just tidying up the design of all of these surfaces
that are all relatively similar.
| Branch Diff | Uncommitted Diff | Single-file Diff | Git Panel |
|--------|--------|--------|--------|
| <img width="800" alt="Screenshot 2026-07-06 at 11 25@2x"
src="https://github.com/user-attachments/assets/4ebf87e7-c52d-41d9-9de3-7944125114a1"
/> | <img width="800" alt="Screenshot 2026-07-06 at 11 25 2@2x"
src="https://github.com/user-attachments/assets/51ccd2eb-904b-455a-a708-b4cb50b3a7cb"
/> | <img width="800" alt="Screenshot 2026-07-06 at 11 26@2x"
src="https://github.com/user-attachments/assets/6ae7df68-d1bd-4d36-a250-ba16e43c4e8e"
/> | <img width="800" alt="Screenshot 2026-07-06 at 11 26 2@2x"
src="https://github.com/user-attachments/assets/e032bc60-4551-41f0-b578-90ed305167c2"
/> |
Release Notes:
- Added diff stat numbers to the uncommitted changes view.
# Add status bar location for inline git blame
## Objective
- Closes#12133 by implementing the VS Code-like behavior for status bar
git blame
## Solution
Adds a VS Code–style option to render the current-line git blame in the
status bar instead of inline at the cursor.
Whats new
- A new location setting: Under the inline_blame configuration, you can
now choose between two options:
- `inline` (Default) — Keeps things exactly as they are, showing the
blame details at the end of your current line.
- `status_bar` — Moves the blame info down to the bottom status bar.
- The Status Bar Item: When you choose the status bar option, a clean
new button appears at the bottom left of your window. It features a Git
icon, the author's name, how long ago the change was made, and the
commit summary
- Behaves as it does before, but displayed at a different location
- Clicking the status bar item will instantly open up the full Git
commit details like at vscode
- Settings UI:
- The "Location" control is now a `DynamicItem` nested under "Enabled",
so it only appears when inline blame is enabled.
- Registers a dropdown renderer for `InlineBlameLocation`.
- Updates `all-settings.md` and `visual-customization.md` for the new
option.
## Testing
- Manually tested both modes by toggling `git.inline_blame.location`
between `inline` and `status_bar`:
- `inline` keeps the existing behavior unchanged.
- `status_bar` shows the blame for the focused line in the status bar,
hides the inline blame, updates on cursor movement, clears when no
editor is focused, and opens the blame commit on click.
- Verified the settings UI shows the "Location" dropdown only when
inline blame is enabled.
- Tested with `show_commit_summary` toggled when location is
`status_bar` (for inline location, nothing is changed)
Areas that could use more testing:
- Remote (collab) editors ?
Reviewers can test by setting the following in `settings.json` and
moving the cursor across blamed lines:
```json
{
"git": {
"inline_blame": {
"enabled": true,
"location": "status_bar"
}
}
}
```
## Showcase
<details>
<summary>Click to view showcase</summary>
### Video
https://github.com/user-attachments/assets/6d9f490d-7bf3-473c-9562-8351546dfaf9
### Screenshots
<img width="894" height="749" alt="image"
src="https://github.com/user-attachments/assets/c6a49008-899d-4a0c-9098-1ffb9e28252b"
/>
</details>
Release Notes:
- Added a `git.inline_blame.location` setting to render current-line git
blame in the status bar instead of inline.
# Objective
This change prevents users from starting multiple Git remote operations
at the same time from the Git panel. Fetch, pull, and push can take
time, may prompt for credentials, and can update shared repository
state, so allowing repeated clicks can create duplicated work, confusing
UI feedback, or overlapping Git commands.
## Solution
The panel now records when a remote operation is in progress, disables
the main remote action button, and shows a clear tooltip such as “Push
in progress.” When the async task exits, the state is cleared and the
button is re-enabled. This keeps the UI aligned with the operation
lifecycle and makes repeated clicks harmless.
---
Release Notes:
- Git: Improved performance by not allowing multiple remote Git
operation to start at the same time.
---------
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
# Objective
- Polish the solo diff review UI by reducing redundant controls and
hiding inactive fold controls in split diff views.
## Solution
- Collapse the solo diff header's `Stage File` / `Unstage File` actions
into one button that shows the action relevant to the file's current
staging state.
- Stop reserving fold gutter space and rendering fold crease toggles for
editors with companion snapshots, matching the existing LHS split diff
behavior.
## Testing
- `cargo fmt --check`
- `cargo check -p git_ui`
## 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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
Before, the solo diff header showed both file-level staging actions at
once, and the RHS split diff gutter could show fold arrows that did not
work in that view. After this change, the header shows the relevant
file-level staging action and split companion panes no longer show
inactive fold controls.
Release Notes:
- Improved solo diff controls by showing the relevant file staging
action and hiding inactive fold toggles in split diffs.
This fixes archive cleanup for agent threads so Zed only removes
worktrees it explicitly created, rather than treating every linked
worktree under the configured managed directory as safe to delete. When
Zed creates a worktree, it now records it in the local database along
with the creation time of the worktree's git metadata directory
(`.git/worktrees/<name>/`). Archive planning requires that record, and
right before deleting anything, Zed re-stats the directory and compares
creation times: if the worktree was removed and recreated outside Zed
(or the time can't be read at all), deletion is skipped and the stale
record is dropped. Every failure mode fails safe by leaving the
directory untouched.
For remote (SSH) projects, the stat runs on the remote host via a new
`GitWorktreeCreatedAt` request. Worktrees created by a different Zed
install (another release channel, or another machine connecting to the
same host) have no record in the local database and are therefore never
auto-archived, which is the intended conservative behavior.
Closes https://github.com/zed-industries/zed/issues/57155
Closes AI-352
Release Notes:
- Fixed archiving an agent thread incorrectly deleting manually-created
git worktrees.
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>
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
Addresses https://github.com/zed-industries/zed/discussions/33773.
This changes git panel file activation so double-clicking or
secondary-opening a changed file opens a dedicated full-file diff tab
backed by a `SplittableEditor`.
The per-file diff reuses the project diff staging and restore controls,
respects the configured diff view style, and focuses an existing
per-file diff tab when one is already open instead of creating
duplicates.
Verified with `cargo run`.
Release Notes:
- Improved git panel file diff opening.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
This primarily
- requires components to have a description as well as a preview
(especially having no preview makes no sense)
- implements some basic previews where missing
- adds a scrollbar to the preview navigation
with a sadly large diff due to reformatting (less indentation 🎉 ), but
very little changes at its core.
Release Notes:
- N/A
Adds a `runtime_diagnostics` section to the dev-only "Show Git Job
Queue" output so that when the queue gets stuck, we can tell from the
dump itself whether a git subprocess is wedged (and on supported
platforms, where it's wedged) without needing the user to run
`ps`/`sample`/`lsof` by hand.
The new section contains:
- **`processes`** — every transitive descendant of the Zed process, with
PID, PPID, name, executable, full argv, sysinfo status
(`Run`/`Sleep`/`Stop`/`Zombie`/etc.), and elapsed runtime.
Cross-platform via `sysinfo`. This is the single most useful field: it
instantly answers "is there a stuck `git` child or not?"
- **`linux_proc`** *(Linux only)* — for each descendant,
`/proc/<pid>/wchan` (the kernel function the thread is sleeping in, e.g.
`futex_wait_queue`, `pipe_read`) and `State:` from `/proc/<pid>/status`.
- **`macos_git_children`** *(macOS only)* — for any descendant whose
name contains `git`, a 2-second `sample` user-space stack and `lsof -p`
output. Each is included only if the corresponding system binary exists;
otherwise it's skipped.
- Windows gets just `processes` (no portable way to grab another
process's stack).
### Safety
- Cross-platform: only `sysinfo` (an existing workspace dep) is on the
always-compiled path. All `sample`/`lsof`/`/proc` code is behind
`#[cfg(target_os = ...)]` gates, so Windows builds never see those
symbols.
- Every fallible step is handled individually: on error it logs a
warning and the corresponding key is omitted from the JSON. The queue
dump is built and shown the same way whether `gather()` returned a
populated object, an empty object, or partial data.
- Diagnostics gather runs under `cx.background_spawn(...)` so the macOS
`sample` 2-second wait can't block the foreground.
- `sample`/`lsof` output is truncated to 64 KB per process at a UTF-8
char boundary.
Release Notes:
- N/A
## 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.
This PR makes Zed only have one worktree picker, as opposed to a flavor
of it in the title bar and another in the agent panel. It then moves it
to the title bar, making it always present, so that its trigger is
separate from the branch picker (which now contains only two views:
branches and stashes). For the worktree picker, I'm mostly favoring the
behavior we've introduced in the agent-panel-flavored version.
It also updates the title bar settings migration to use the JSON
`migrate_settings` helper instead of a shallow Tree-sitter rewrite, so
old `show_branch_icon = true` values are promoted to
`show_branch_status_icon = true` across root, platform, release-channel,
and profile settings scopes.
- [x] Move worktree creation logic to the `git_ui` crate to make this
more generic and less agent-specific
- [x] Double-check the remote use case and ensure nothing broke there
- [x] Improve the UX for the detached HEAD state; better invite people
to create a branch
- [x] Migrate `show_branch_icon = true` to `show_branch_status_icon =
true` across nested settings scopes
Suggested .rules additions
When migrating renamed settings keys that can appear in platform
overrides, release-channel overrides, or profiles, prefer the JSON
`migrations::migrate_settings` helper over shallow Tree-sitter key
rewrites unless tests explicitly cover every nested scope that can
contain the key.
Release Notes:
- Improved migration of the title bar branch status icon setting.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Ben Brandt <benjamin.j.brandt@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>
This changes the behavior of the recent project picker in multi-folder
projects, so that when you select a folder that is a repository, it sets
the active repository in the Git panel as well.
Release Notes:
- N/A
Follow up to https://github.com/zed-industries/zed/pull/49807
Previously, when there were multiple conflicts across the codebase, we
would pop a toast at the bottom right corner of the UI. A toast seemed
like a functional idea because it'd be visible from any state of the app
and thus it'd be a good place to expose the button that allows you to
quickly prompt the agent to resolve all conflicts, as opposed to
creating a thread for each individual one. However, the toast was met
with some negative (and correct) feedback, mostly because it is
interruptive, and thus can sometimes block very relevant surfaces, like
either the agent panel itself or the Git commit area.
Therefore, in this PR, I'm removing the toast and adding a button in the
status bar instead; a bit more minimal, not interruptive, and a common
place for other items that might require your attention. The status bar
can be quite busy these days, though; we can display diagnostics, LSP
status, and file names in there; conscious of that. But it felt like it
could work given this button is such a transient one that you can either
easily manually dismiss or wait for it to be auto-dismissed as you or
the agent resolves the merge conflicts.
<img width="500" height="864" alt="Screenshot 2026-04-02 at 9 15@2x"
src="https://github.com/user-attachments/assets/4412a05c-77d0-4391-8ea1-25d1749b5e20"
/>
Release Notes:
- Git: Improved how we surface the affordance to resolve codebase-wide
merge conflicts with the agent in the UI.
- Agent: Added a setting to control whether or not the button to resolve
merge conflicts with the agent should be displayed.
## Context
I have a project with a nested git repo inside a parent repo (separate
`.git` directory, not a submodule). The title bar shows the parent's
branch instead of the nested repo's own branch.
The issue is in `get_repository_for_worktree()` — it iterates
`git_store.repositories()` (an `FxHashMap`) and returns the first
`starts_with` match. Both the parent and nested repo match, and
whichever one FxHashMap iterates first wins. There's no reason it should
be one or the other.
The fix already exists elsewhere in the codebase —
`GitStore::repository_and_path_for_project_path()` at
`git_store.rs:1826` uses `.max_by_key()` to pick the most specific
(longest path) match. This PR applies the same approach to three
functions that have the same problem:
- `TitleBar::get_repository_for_worktree()` — branch display in title
bar
- `resolve_active_repository()` in `git_ui` — repository selection for
the git panel
- `get_branch_for_worktree()` in `recent_projects` — branch display in
the project switcher
Two other locations use a similar `starts_with` pattern
(`effective_active_worktree()` in `title_bar.rs` and worktree selection
in `recent_projects.rs`) but those iterate worktrees against a single
known repo, not repos against a worktree — so first-match and
longest-match give the same result. Left those unchanged.
Closes#7566
## How to Review
All three changes are the same transformation: first-match loop (or
`.find()`) → `.filter().max_by_key()` on path length. The reference is
at `crates/project/src/git_store.rs:1826`.
The primary fix is `get_repository_for_worktree()` in `title_bar.rs`.
The other two are the same pattern.
One difference from the reference: I used `.as_os_str().len()` instead
of `.clone()` for the `max_by_key` key — avoids cloning an `Arc<Path>`
per comparison. Among prefix-related paths (which is all that passes the
filter), the longer path is always the more specific match, so length
comparison is equivalent.
`title_bar` has no existing test infrastructure. Happy to add a test if
you'd like — the setup would follow the pattern in
`test_git_traversal_with_nested_repos`
(`crates/project/tests/integration/git_store.rs`).
```
cargo test -p title_bar -p git_ui -p recent_projects
./script/clippy
```
## 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:
- Fixed branch picker showing parent repository's branch instead of the
nested repository's branch when working in submodules or nested git
repos.
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Previously, if you wanted to have a button that contains icons on both
edges, you'd need to use a `ButtonLike` component, which takes any
children. Meanwhile, the `Button` would only take one icon, where you
could control its position through the `IconPosition` enum. This has
always felt unnecessarily limiting. So, this PR removes this limitation
by adding two new methods to the button: `start_icon` and `end_icon`.
In the meantime, I have also been bothered by the unnecessary
indirection in the `IconButton` due to the existence of the `ButtonIcon`
component. So I figured I could also completely eliminate that by adding
some of its methods directly to the `IconButton` and in the Button, just
using a regular `Icon` component.
---
## Before
```rust
Button::new("id", "Label")
.icon(IconName::Plus)
.icon_position(IconPosition::Start)
.icon_size(IconSize::Small)
.icon_color(Color::Muted)
```
## After
```rust
Button::new("id", "Label")
.start_icon(Icon::new(IconName::Check))
.end_icon(Icon::new(IconName::ChevronDown).size(IconSize::XSmall))
```
This should have no visual impact to the UI.
Release Notes:
- N/A
This PR adds a "Resolve with Agent" button in each merge conflict block,
as well as "Resolve Conflicts with Agents" button on a notification for
resolving conflicts across all the files that have any. When clicking on
either of these buttons, the agent panel opens up with a template prompt
auto-submitted. For the first case, the specific content of the merge
block is already attached as context for the agent to act quickly, given
it's a local and small context. For the second case (all conflicts
across the codebase), the prompt just indicates to the agent which files
have conflicts and then it's up for the agent to see them. This felt
like a simpler way to go as opposed to extracting the content for all
merge conflicts across all damaged files.
Here's how the UI looks like:
<img width="550" height="1964" alt="Screenshot 2026-02-21 at 11 04@2x"
src="https://github.com/user-attachments/assets/96815545-ba03-40e5-9cb0-db0ce9588915"
/>
---
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:
- Git: Added the ability to quickly resolve merge conflicts with the
agent.
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Remove both `git::LoadMoreHistory` and `git::ViewCommitFromHistory`
actions as although both actions were registered in the workspace, they
don't actually have effect when run.
This appears to have been leftover from
https://github.com/zed-industries/zed/pull/42441 , possibly the initial
implementation on how to open a commit and load more commits when the
file history view was open, which is now handled with `Button.on_click`
callbacks instead of relying on actions.
Closes#49288
Release Notes:
- Removed unused git actions – `git: load more history` and `git: view
commit from history`
This PR removes onboarding modals for features that were announced, at
this point, a long time ago: Git v1, Debugger, and Agent Panel v1. This
cleans up the actions list a bit when you search for "onboarding". I
left the ACP and Claude Code ones, though; they were the two more recent
ones, but we should be able to remove them soon enough, too.
Release Notes:
- N/A
This branch:
1. teaches `--diff `command line option to to recurse into folders if
provided.
2. Adds a `MultiDiffView` that shows _all_ changed files in a single,
scrollable view.
This is necessary to provide a smooth user experience for `jj` and Zed
users who wish to use Zed as their jj difftool.
I'm not fully sure how this change interacts with
https://github.com/zed-industries/zed/pull/44936, or what plans y'all
have in mind.
Here's a screenshot of the resulting behavior:
<img width="1090" height="950" alt="Screenshot 2025-12-17 at 9 10 52 AM"
src="https://github.com/user-attachments/assets/8efd09b4-974f-4059-9f94-539c484c6d4a"
/>
I setup zed to handle jj diffs by adding the following to my jj config:
```toml
[aliases]
zdiff = ["diff", "--tool", "zed"]
[merge-tools.zed]
program = "/Users/dbarsky/Developer/zed/target/debug/cli"
# omit diff-invocation-mode to keep the default (JJ passes two dirs)
diff-args = [
"--zed", "/Users/dbarsky/Developer/zed/target/debug/zed",
"--wait",
"--new",
"--diff",
"$left",
"$right",
]
```
Release Notes:
- `--diff`, if provided with folders instead of files, will recurse into
those directories.
- Added a `MultiDiffView`, which will show all changed files within a
single, scrollable view.
**AI Disclosure**: Pretty much all of this code was written using Codex
with GPT-5.1-Codex. I edited by hand and tested this.
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
This PR creates a unified picker for all the Git-related pickers:
branch, worktree and stash. The main motivation for this is to bring
awareness and ease of access for the worktree and stash pickers that
were previously (and arguably) hidden amidst the sea of commands in the
command palette. As worktrees in particular become more relevant for
AI-related flows, having an easier way to reach for its picker will be
beneficial.
Note that the actions/commands remain the same; you can still look for
`git: worktree` or `git: view stash`. The difference is that these
actions will take you to the unified picker with the correct
corresponding active view.
https://github.com/user-attachments/assets/99d1cd6f-a19d-47d3-9bca-d7257e7ed5b8
Release Notes:
- Git: Unify the branch, worktree, and stash pickers into one, making it
easier to find and access them from one another.
Closes#42217
Release Notes:
- Added/Fixed/Improved ...
added "Create Pull Request" Command when searching on the command
Palette
For more details, please refer to the issue, thank you.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Closes #ISSUE
Problem:
- The status bar’s pending keystroke indicator (shown next to --NORMAL--
in Vim mode) didn’t clear when focus moved to another context, e.g.
hitting g in the editor then clicking the Git panel. The keymap state
correctly canceled the prefix, but observers that render the indicator
never received a “pending input changed” notification, so the UI kept
showing stale prefixes until a new keystroke occurred.
Fix:
- The change introduces a `pending_input_changed_queued` flag and a new
helper `notify_pending_input_if_needed` which will flushes the queued
notification as soon as we have an App context. The
`pending_input_changed` now resets the flag after notifying subscribers.
Before:
https://github.com/user-attachments/assets/7bec4c34-acbf-42bd-b0d1-88df5ff099aa
After:
https://github.com/user-attachments/assets/2264dc93-3405-4d63-ad8f-50ada6733ae7
Release Notes:
- Fixed: pending keybinding prefixes on the status bar now clear
immediately when focus moves to another panel or UI context.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This reverts commit b0a7defd09.
It looks like this doesn't interact correctly with the project diff or
with staging, let's revert and reland with bugs fixed.
Release Notes:
- N/A
- Adds a new action `git::PullRebase` which adds `--rebase` in the final
command invoked by existing Git-Pull implementation.
- Includes the new action in "Fetch/Push" button in the Git Panel
(screenshot below)
- Adds key-binding for `git::PullRebase` in all three platforms,
following the existing key-binding patterns (`ctrl-g shift-down`)
- Update git docs to include the new action.
Sidenote: This is my first ever OSS contribution
Screenshot:
<img width="234" height="215" alt="image"
src="https://github.com/user-attachments/assets/713d068f-5ea5-444f-8d66-444ca65affc8"
/>
---
Release Notes:
- Git: Added `git: pull rebase` for running `git pull --rebase`.
Related discussions #26084
Worktree creations are implemented similar to how branch creations are
handled on the branch picker (the user types a new name that's not on
the list and a new entry option appears to create a new branch with that
name).
https://github.com/user-attachments/assets/39e58983-740c-4a91-be88-57ef95aed85b
With this picker you have a few workflows:
- Open the picker and type the name of a branch that's checked out on an
existing worktree:
- Press enter to open the worktree on a new window
- Press ctrl-enter to open the worktree and replace the current window
- Open the picker and type the name of a new branch or an existing one
that's not checked out in another worktree:
- Press enter to create the worktree and open in a new window. If the
branch doesn't exists, we will create a new one based on the branch you
have currently checked out. If the branch does exists then we create a
worktree with that branch checked out.
- Press ctrl-enter to do everything on the previous point but instead,
replace the current window with the new worktre.
- Open the picker and type the name of a new branch or an existing one
that's not checked out in another worktree:
- If a default branch is detected on the repo, you can create a new
worktree based on that branch by pressing ctrl-enter or
ctrl-shift-enter. The first one will open a new window and the last one
will replace the current one.
Note: If you preffer to not use the system prompt for choosing a
directory, you can set `"use_system_path_prompts": false` in zed
settings.
Release Notes:
- Added git worktree picker to open a git worktree on a new window or
replace the current one
- Added git worktree creation action
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Closes#39172
This refactors when we resolve UI keybindings in an effort to reduce
flickering whilst painting these: Previously, we would always resolve
these upon creating the binding. This could lead to cases where the
corresponding context was not yet available and no binding could be
resolved, even if the binding was then available on the next presented
frame. Following that, on the next rerender of whatever requested this
keybinding, the keybind for that context would then be found, we would
render that and then also win a layout shift in that process, as we went
from nothing rendered to something rendered between these frames.
With these changes, this now happens less often, because we only look
for the keybinding once the context can actually be resolved in the
window.
| Before | After |
| --- | --- |
|
https://github.com/user-attachments/assets/adebf8ac-217d-4c7f-ae5a-bab3aa0b0ee8
|
https://github.com/user-attachments/assets/70a82b4b-488f-4a9f-94d7-b6d0a49aada9
|
Also reduced cloning in the keymap editor in this process, since that
requiered changing due to this anyway.
Release Notes:
- Fixed some cases where keybinds would appear with a slight delay,
causing a flicker in the process
Continues the work from #35927 to add a git diff view for stash entries.
[Screencast From 2025-09-17
19-46-01.webm](https://github.com/user-attachments/assets/ded33782-adef-4696-8e34-3665911c09c7)
Stash entries are [represented as
commits](https://git-scm.com/docs/git-stash#_discussion) except they
have up to 3 parents:
```
.----W (this is the stash entry)
/ /|
-----H----I |
\|
U
```
Where `H` is the `HEAD` commit, `I` is a commit that records the state
of the index, and `U` is another commit that records untracked files
(when using `git stash -u`).
Given this, I modified the existing commit view struct to allow loading
stash and commits entries with git sha identifier so that we can get a
similar git diff view for both of them.
The stash diff is generated by comparing the stash commit with its
parent (`<commit>^` or `H` in the diagram) which generates the same diff
as doing `git stash show -p <stash entry>`. This *can* be
counter-intuitive since a user may expect the comparison to be made
between the stash commit and the current commit (`HEAD`), but given that
the default behavior in git cli is to compare with the stash parent, I
went for that approach.
Hoping to get some feedback from a Zed team member to see if they agree
with this approach.
Release Notes:
- Add git diff view for stash entries
- Add toolbar on git diff view for stash entries
- Prompt before executing a destructive stash action on diff view
- Fix commit view for merge commits (see #38289)
Closes #ISSUE
This PR continues work from #32821 by adding a stash entry picker for
pop/drop operations. Additionally, the stash pop action in the git panel
is now disabled when no stash entries exist, preventing error logs from
attempted pops on empty stashes.
Preview:
<img width="1920" height="1256" alt="Screenshot From 2025-09-11
14-08-31"
src="https://github.com/user-attachments/assets/b2f32974-8c69-4e50-8951-24ab2cf93c12"
/>
<img width="1920" height="1256" alt="Screenshot From 2025-09-11
14-08-12"
src="https://github.com/user-attachments/assets/992ce237-43c9-456e-979c-c2e2149d633e"
/>
Release Notes:
- Added a stash picker to pop and drop a specific stash entry
- Disabled the stash pop action on the git panel when no stash entries
exist
- Added git stash apply command
- Added git stash drop command
Piotr Osiewicz
