this pr enables opening a specific line in a diff using zed's cli
Release Notes:
- refactor: add possibility to open specific line in a diff using the
cli
---------
Co-authored-by: Cole Miller <cole@zed.dev>
# Objective
- Show accurate diff stats for each staged and unstaged projection of a
partially staged file in the Git panel.
- This was originally considered for
https://github.com/zed-industries/zed/pull/59884, but was scoped out of
that already-large PR and is being submitted separately as discussed
there.
## Solution
- Collect HEAD-to-index and index-to-worktree diff stats alongside the
existing combined HEAD-to-worktree stats.
- Carry the staged and unstaged stats through repository status
snapshots and remote status serialization.
- Use the stat matching the projected Git panel section while preserving
the combined stat for the other grouping modes.
- Update the fake Git repository and add regression coverage with
deliberately different staged and unstaged counts.
## Testing
- `cargo check -p git_ui`
- `cargo check -p collab`
- `cargo test -p git_ui
test_group_by_staging_section_membership_and_order --lib`
- `cargo test -p project --lib --no-run`
- `cargo fmt --all -- --check`
- `git diff --check`
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed diff stats for partially staged files in the Git panel
This PR removes the commit preview popover when hovering over rows in
the git graph. In my humble opinion, I've been finding that having the
hover preview damages the usability/readability of the graph. I can't
properly read each row's content and understand its place on the graph
if everywhere I rest my cursor in a popover appears... Moreover, almost
all of the information we display in the commit preview is already
displayed in the row itsself, and if you'd like to drill down into the
commit description and whatnot, clicking the row opens the commit drawer
and gives you that and even more information (e.g., set of changed
files, etc.).
Release Notes:
- N/A
Follow-up to zed-industries/zed#60721.
The Taffy 0.12 upgrade exposed that the message height limit was applied
to its grid parent while percentage-sized children retained the Markdown
content's intrinsic height. Long messages therefore painted over the
changed-files summary instead of scrolling.
Move the height limit to the scroll container itself, matching the
commit view. Add a GPUI regression test that verifies the viewport stays
bounded, remains scrollable, and does not overlap the changed-files
list.
> On `main`:
<img width="697" height="873" alt="Screenshot 2026-07-17 at 14 59 21"
src="https://github.com/user-attachments/assets/51e6cc0e-aeac-4ad1-a6af-2120efcef901"
/>
---
Release Notes:
- N/A
# Objective
Add remote (SSH) and collaboration support for trashing and restoring
files in the project panel, which in turn enables undo/redo of trash
operations against remote and collab projects.
Relates to #5039.
## Solution
- Updated the project panel undo system to carry `TrashId` instead of
`TrashedEntry`.
- Using `TrashedEntry` could get hairy, as it includes paths, which
wouldn't play too nicely when using, for exapmle, macOS as the client
and Windows as the host. Using a simple identifier is much easier in
this regard and simplifies implementation.
- Enabled the Trash action and context-menu entry on remote projects,
and removed the command palette filter in `ProjectPanel::new` that was
still hiding the action on remote.
- As far as I can tell, there isn't a reliable way to detect whether a
given remote actually supports the OS trash, so we expose the action
everywhere rather than guessing. On a remote without trash support the
action will fail when invoked but this is a conscious tradeoff until we
find a better way to handle this.
- `fs` now tracks trashed files in a `SlotMap<TrashId, TrashedEntry>` on
each `Fs` implementation. Trashed files are referenced by an opaque
`TrashId` instead of passing a `TrashedEntry` around, which avoids
serializing filesystem paths in remote messages.
- Split the old `delete_entry(trash: bool)` API into distinct
`trash_entry`/`trash_file` (returning a `TrashId`) and
`delete_entry`/`delete_file` across `Project`, `Worktree`,
`LocalWorktree` and `RemoteWorktree`.
- This lets us drop the optional trash result (`Option<TrashedEntry>`)
from the delete path and require a `TrashId` from the trash path.
- Added new proto messages (`TrashProjectEntry`,
`TrashProjectEntryResponse`, `RestoreProjectEntry`,
`RestoreProjectEntryResponse`) to let clients request the host to trash
or restore entries.
- This deprecates `DeleteProjectEntry::use_trash`, but the host still
honors it. An older collab peer may request trashing via that flag
instead of the newer `TrashProjectEntry`. If the host ignored it, a
newer host would permanently delete a file the user meant to send to the
trash. The field will be removed in a later PR once all supported peers
use `TrashProjectEntry`.
## Testing
The following tests were introduced to ensure the new behavior is
correctly tested:
* `remote_server::remote_editing_tests::test_remote_trash_restore` –
Tests trashing a project entry in remote
*
`remote_server::remote_editing_tests::test_remote_delete_project_entry_with_trash`
– Test to ensure we continue respecting `DeleteProjectEntry::use_trash`
until it is fully removed
* `project_panel::tests::undo::trash_directory_undo_redo` – Not related
to these changes but a nice to have as we were missing a test ensuring
that trashing and then undoing and redoing it for a directory works as
expected
Besides these, the following scenarios were manually tested against a
remote session on the same machine (macOS):
- Trashing → Undo (Restore) → Redo (Trashing)
- Batch Trashing → Undo (Batch Restore) → Redo (Batch Trashing)
- Rename → Undo (Rename) → Redo (Rename)
- Move → Undo (Move) → Redo (Move)
- Batch Move → Undo (Batch Move) → Redo (Batch Move)
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Yara <git@yara.blue>
This is necessary to remove some `util` dependencies from crates, as
well as better sharing for our projects. This also includes the WIP
AbsPath abstraction as well as some bug fixes from internal tooling.
Release Notes:
- N/A or Added/Fixed/Improved ...
Follow up to https://github.com/zed-industries/zed/pull/59884
This PR refines how the git panel behaves when grouping changes by
staging state, with a focus on making staging workflows predictable and
conflict resolution safe.
- Renamed the "Group By" menu options to describe what you actually see:
**"Tracked & Untracked"** (was "Status") and **"Staged & Unstaged"**
(was "Staging").
- When grouping by staged & unstaged, both sections now stay visible
even when empty, showing a placeholder message ("No staged changes yet"
/ "No unstaged changes"). Previously an empty section disappeared
entirely, which made the panel layout jump around as you staged and
unstaged files, and made it harder to tell at a glance that nothing was
staged yet.
- Section header controls are now consistent checkboxes everywhere
(previously a mix of checkboxes and +/− icon buttons), with "Stage All"
/ "Unstage All" tooltips. Headers of empty sections render no checkbox
and don't react to clicks or hover. I appreciate the debate that
happened in the PR linked above about this but I was personally having a
hard time understanding what was the difference in interaction given the
action was exactly the same, we were just having different UIs, which
looked inconsistent.
- Arrow-key navigation now skips over section headers and empty-section
placeholder rows in both flat and tree view, instead of getting stuck or
selecting non-interactive rows — including when jumping to the first or
last entry.
- In the staged & unstaged grouping, a partially staged file appears in
both sections. Each row's checkbox and tooltip now follow the section
it's rendered in: rows in Staged always unstage, rows in Unstaged always
stage — including via shift-click range operations, which now also
support bulk *unstaging* within the Staged section (previously ranges
could only stage). The context menu's Stage/Unstage label follows the
same rule and stays in sync with in-flight staging operations.
- Conflicted files are grouped by whether the current merge marked them
conflicted (rather than raw status), so a conflict you've resolved stays
visible under "Conflicts" until the merge concludes. On top of that,
resolution is now one-way in the UI:
- Ticking a conflicted file's checkbox marks it resolved (stages it).
Once resolved, the checkbox is disabled with a "Conflict marked as
resolved" tooltip — unticking it would silently discard git's record of
the unmerged base/ours/theirs versions, a round-trip git can't actually
perform.
- The same lock applies everywhere the file can be reached: the keyboard
toggle, folder checkboxes in tree view, the Conflicts section header
(disabled once all conflicts are resolved), "Stage All"/"Unstage All" on
the Staged/Unstaged headers, and shift-click range sweeps — none of them
will resolve or un-resolve a conflict as a side effect.
- The explicit `git: unstage file` action still works as a deliberate
escape hatch.
---
Here's a video, where you can see I stage and unstage whole files, make
a partial staging, and get into a merge-conflict state, where the
conflicted files are tagged as resolved:
https://github.com/user-attachments/assets/d27ef9c6-5691-45c1-91ab-c3b152aaaa60
---
Release Notes:
- N/A _(given the feature hasn't been released yet_)
This PR adds a series of design improvements to the branch picker,
including:
- Consistent icon used for filter actions
- A keybinding/action to trigger the filter menu with the keyboard
- Filter menu positioning depending on the picker's editor position
- Error display that displays the full label without truncation/tooltip,
and is placed accordingly also depending on the picker's editor position
- List subheader in the search list depending on filtered option
Here's a quick video:
https://github.com/user-attachments/assets/70922daf-fc9f-4d94-bed8-c84d3ea73534
- - -
Release Notes:
- N/A
This PR is a collection of grab bag UI design refinements across the
entire app. Most of them are minor icon fixes/standardizations, spacing,
and sizing tweaks.
The one change that ended up getting a bit bigger than I initially
anticipated is the debugger panel tabs improvements; added a bunch of
tweaks there to make it look slicker. A relevant change is a small
one-line change to the GPUI div element where it wouldn't add drag-over
styles to elements that aren't initially a hitbox target. Given I wanted
to pull off the drop indicator you see on the video below, this turned
out to be needed:
https://github.com/user-attachments/assets/964b456a-eef0-42bb-a433-7dac54ab8ec8
---
Release Notes:
- N/A
Fetch tag names for commits included in blame data and pass them through
the blame rendering path. Render tag names as chips in the blame hover
tooltip and expanded blame popover. Tag lookup is best-effort, so blame
still renders if tag lookup fails.
> Note: Tag names are currently only fetched for local repositories. For
remote projects (SSH) and collab sessions, blame data travels over the
`BlameBufferResponse` proto message, which doesn't carry tag names yet.
## Testing
- `cargo test -p git
test_parse_tag_names_for_lightweight_and_annotated_tags`
- `cargo check -p git_ui`
- `cargo check -p editor`
- `cargo check -p project`
Manual testing:
- Opened `git: blame` on a file with a tagged commit.
- Verified tag chips are shown in the blame hover tooltip and expanded
popover.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and [icon]
(https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
Before:
<img width="1655" height="660" alt="before"
src="https://github.com/user-attachments/assets/dbefd729-f8df-48a9-8249-83c93518fe76"
/>
After:
<img width="1655" height="660" alt="after"
src="https://github.com/user-attachments/assets/2c1097de-b268-45d9-9d13-0f3e06058603"
/>
---
Release Notes:
- Git: Made tags visible in Git blame tooltips.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This PR reworks how multi-select mode is rendered in pickers (only used
by the file finder and text finder).
The "Multi Select" entry previously lived inside the footer's Actions
menu, which was hard to discover and its toggle checkmark misaligned the
menu's keybinding column. This PR changes to an icon button at the
far-roght edge of the search editor, with a tooltip showing the
keybinding to toggle it.
Also made each list item use the actual Checkbox component instead of a
bespoke re-implementation of it. And in doing so, added a few design
improvements to the list item so that it received the checkbox while
preserving proper styles for each interaction state, as well as
displaying the keybinding to select the item or check the item.
Here's a quick video, showing these changes off:
https://github.com/user-attachments/assets/e142f7d1-87ba-4258-844b-953ed06237bd
Release Notes:
- Improved multi-select in the file finder and text finder: the toggle
now lives in the search bar with a `cmd-shift-s` keybinding, and
selection checkboxes render inside list items.
Fixes menu a11y, and adds landmarks with `F6`-navigation.
Also fixes a GPUI bug, and adds debug actions for dumping a11y tree
info.
Since `F6` was already in use by the pause debugger keybind, also
tightens up the debugger keybind context so they require an active
debugger session. When there is one active, `F6` stays as pause
debugger. `ctrl-F6` always works to go to the next landmark.
Also adds an "accessible mode" setting. Currently, this only controls
whether we show all menus all the time, but I suspect it will expand
significantly in the future.
Also adds `.aria_keyshortcuts()` API, but it's not wired up within
accesskit adapters, so is not yet reported to screen readers.
---
Release Notes:
- N/A or Added/Fixed/Improved ...
The branch picker collapses remote branches that are tracked by a local
branch (e.g. `origin/main` when local `main` tracks it). That makes
sense for checkout, where the remote ref is redundant, but it was also
applied to the branch diff base picker, where `main` and `origin/main`
can point to different commits. As a result, once you switched the diff
base from `origin/main` to `main`, there was no way to switch back.
The tracked-remote collapsing is now only applied in checkout mode (no
changed here). The select (diff base) picker lists both local branches
and their remote upstreams.
Release Notes:
- Fixed remote branches (e.g. `origin/main`) not appearing in the branch
diff base picker, making it impossible to switch back after changing the
base to another branch.
# Objective
Make branch filtering consistent and more flexible across the title bar
and Git panel branch pickers.
## Solution
- Replace the remote-only filter toggle with a dropdown for all, local,
and remote branches.
- Preserve the selected filter across branch picker instances.
- Add a ListFilter icon and active-filter indicator.
- Prevent nested filter-menu interactions from dismissing the parent
picker.
- Cycle through all, local, and remote filters with the existing
keyboard shortcut.
## Testing
- Ran `cargo check -p git_ui --tests --no-default-features`.
- Verified formatting with `cargo fmt -p git_ui`.
- Manually checked the filter dropdown from the title bar and Git panel.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
- Filters: All, Local, Remote
- "Cmd + Shift + I" to cycle over the filters
<details>
<summary>New Branch Picker Filter Dropdown</summary>
<img width="1624" height="1030" alt="Screenshot 2026-07-12 at 3 53
30 PM"
src="https://github.com/user-attachments/assets/1323d9c9-f4b9-41ee-ba93-841299872c02"
/>
<img width="1624" height="1030" alt="Screenshot 2026-07-12 at 3 54
35 PM"
src="https://github.com/user-attachments/assets/839345ff-de3b-48f0-b4e7-0f8d27e94204"
/>
</details>
Release Notes:
- Improved branch filtering with local, remote, and all-branch options
in the branch picker.
# Objective
`GitPanel::entry_label` builds file-name labels directly from `git
status` output without calling `.single_line()`. A raw newline in a file
name splits its row across multiple visual lines in the Changes panel.
## Solution
- Add the missing `.single_line()` call in `entry_label`, matching the
behavior in `project_panel.rs`.
## Testing
- Created a git repo with an untracked file whose name contains a
literal newline byte and confirmed the Changes panel now renders it on
one line, collapsing the newline to `⏎` like the project panel already
does.
## 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 adheres to Zed's UI standards
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
# Showcase
Before:
<img width="441" height="216" alt="image"
src="https://github.com/user-attachments/assets/921e5aad-01f9-49fd-89b1-f7270e2d203c"
/>
After:
<img width="447" height="206" alt="image"
src="https://github.com/user-attachments/assets/1c09af36-ccf1-434a-be20-0ea2c5d232d5"
/>
Release Notes:
- Fixed file names containing newlines rendering across multiple
lines in the Git Panel.
The unstaged diff view introduced in the partially staged changes commit
only had a Stage button but no Restore option. This adds:
- A per-hunk Restore button in the inline hunk controls (disabled for
new files)
- A Restore button in the toolbar for selected hunks
- A Restore All button in the toolbar to discard all unstaged changes
- A restore method override on UnstagedDiffDelegate for the Restore
action
Release Notes:
- Added restore buttons to the unstaged diff view for discarding
unstaged changes.
# Objective
New unstaged and staged diffs were added in #46541 . However for
unstaged changes, only option available is to stage a change. It would
also be a common use case to restore the changes. (Like how it is done
in uncommitted changes).
## Solution
- A per-hunk Restore button in the inline hunk controls (disabled for
new files)
- A Restore button in the toolbar for selected hunks
- A Restore All button in the toolbar to discard all unstaged changes
- A restore method override on UnstagedDiffDelegate for the Restore
action
## Testing
Tested in locally and ensured both features work
## Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
## Showcase
<img width="1141" height="635" alt="Screenshot 2026-07-09 at 9 00 47 AM"
src="https://github.com/user-attachments/assets/b1d3f091-9f1d-49c6-87e6-9efad25e62dd"
/>
## Note
I am still learning rust bit by bit. Please let me know if something is
massively wrong. This is assisted by AI but reviewed by me with best of
my knowledge.
---
Release Notes:
- Added restore buttons to the unstaged diff view for discarding
unstaged changes.
---------
Signed-off-by: Pranav <pranav10121@gmail.com>
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
# Objective
- Add a view option for group by staging.
## Solution
- Add a new option for group_by under git_panel view options, with 2
sections "Staged" and "Unstaged", with buttons (+/-) to stage and
unstage
## Testing
- 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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
<img width="1679" height="1140" alt="Screenshot 2026-06-25 at 2 09
44 PM"
src="https://github.com/user-attachments/assets/1b605cad-7792-4823-983c-ada41be25504"
/>
---
Release Notes:
- Added group by staging view option
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
This PR fixes a few History tab edge cases in the Git Panel.
For a fresh repo with no commits, the History tab now finishes loading
and shows No commits yet instead
of sitting on Loading… indefinitely or falling into a misleading
empty/error state.
It also fixes detached HEAD history loading. In that case, the Git Panel
asks the backend to load history
from the current commit SHA. The local git backend was accidentally
treating the raw object ID bytes as a
string instead of formatting them as a normal hex SHA, so git log could
fail before returning any
commits. The backend now passes the SHA in the format git expects.
**Repro for empty repo:**
mkdir /tmp/zed-empty-history
cd /tmp/zed-empty-history
git init
zed .
Open Git Panel → History.
Before: History could stay stuck on Loading….
After: History shows No commits yet.
**Repro for detached HEAD:**
mkdir /tmp/zed-detached-history
cd /tmp/zed-detached-history
git init
echo hi > file
git add file
git commit -m initial
git checkout --detach HEAD
zed .
Open Git Panel → History.
Before: History could fail to load commits.
After: History shows the commit history normally.
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:
- Fixed Git history tab states for empty repositories and detached HEAD
history.
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Fixes#53527.
## Summary
- Suggest `untitled.<extension>` when saving an untitled editor buffer
with a selected non-Plain Text language.
- Preserve the existing title-based suggestion for existing files, Plain
Text buffers, and buffers without a language extension.
- Add a regression test for an untitled Rust buffer suggesting
`untitled.rs`.
## Testing
- `mise exec rust@1.95.0 -- cargo fmt --check -p editor`
- `mise exec rust@1.95.0 -- cargo test -p editor
test_suggested_filename_uses_language_extension_for_untitled_buffer
--lib`
## Suggested .rules additions
None.
Release Notes:
- Fixed Save As suggestions for untitled buffers with a selected
language.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
## Summary
Fixes#60288 and #60454 .
After a push, the push toast's "Create Pull Request" button fails with
`Unsupported remote URL` when the repository's remote is not a plain,
recognized host. This restores the pre-#53913 behavior as a fallback:
use the create-PR/MR link that `git push` itself prints, and only build
a URL from the provider registry when the push output had no link.
## Why this matters
#53913 made the button always appear and changed `create_pull_request`
to reconstruct the PR URL from the remote via
`git::parse_git_remote_url` against the `GitHostingProviderRegistry`.
When the remote is not recognized, parsing returns `None` and the action
errors. This affects self-hosted GitLab/GitHub, an SSH-config host alias
like `git@personal:owner/repo` (the duplicate #60076), and any
non-standard host. Before #53913, the flow used the link git prints in
the push output, which works regardless of host, so this is a regression
for anyone not pushing to a plainly-recognized GitHub URL.
## Solution
`git push` prints a `remote:` line with the hosting provider's
create-PR/MR URL (GitHub: "Create a pull request for '\<branch>' on
GitHub by visiting:", GitLab: "To create a merge request for \<branch>,
visit:", Bitbucket: "Create pull request for \<branch>:"), and we
already hold the push `RemoteCommandOutput`.
- `remote_output.rs`: add `extract_pull_request_url`, which scans the
push stderr for the first `http(s)` URL on a `remote:` line tied to a
create-PR/MR prompt. It ignores unrelated URLs (for example the OpenSSH
post-quantum warning line).
- `git_panel.rs`: capture that URL in `show_remote_output` into
`pending_pull_request_url`, and prefer it in `create_pull_request`,
falling back to the existing provider construction only when the push
output had no link. The cached URL is consumed once (`take()`) and
cleared when the active repo, the active branch/head, or the pending
remote operation changes, so a later `git: Create Pull Request` action
never opens a stale URL from an earlier push.
Recognized GitHub remotes are unaffected: they still get a link from the
push output, with the provider path as the fallback.
## Testing
Unit tests in `remote_output.rs` cover `extract_pull_request_url` for
the GitHub, GitLab, and Bitbucket prompt formats, the no-link case
(returns `None`, so the provider fallback runs), and an output
containing an unrelated URL that must not be mistaken for the PR link.
The existing remote-operation test also asserts the cached URL is
cleared when a new operation starts.
`cargo test -p git_ui remote_output` passes (5 tests). Tested 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] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed "Create Pull Request" button in the toast shown after `git:
push` failing for repositories on unrecognized Git hosts by using the
link printed in the push output.
- Fixed the button shown on the toast after `git: push` for GitLab
branches with an existing merge request. It now shows "View Merge
Request" and links to the existing merge request.
---------
Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
Co-authored-by: dino <dinojoaocosta@gmail.com>
# Objective
Ensure that all existing panels have corresponding menu items in the
"View" menu. I was onboarding a friend to Zed yesterday that was having
a hard time figuring out how to interact with the Agent. Although he did
open the "View" menu, I noticed that the Agent panel item was missing
from there, making it hard for new users to discover it exists.
## Solution
* Add both "Agent Panel" and "Git Panel" entries to the menu items for
the "View" app menu.
* Update the action used for the "Terminal Panel" menu item from
`terminal_panel::ToggleFocus` to `terminal_panel::Toggle` to ensure we
display a shortcut for this menu item.
* Another valid option would be to update the default keymap to use
`terminal_panel::ToggleFocus` instead but that would probably break
existing user's expectations that the default shortcut toggles the
terminal panel, instead of toggling its focus.
* Introduce `zed_actions::git_panel` to be able to extract its
`ToggleFocus` action, following the existing pattern.
### Next Steps
It's worth noting that, even though there's now an "Agent Panel" item
mapped to the `assistant::ToggleFocus` action, its default keybinding is
not displayed (at least on macOS), because of the way it's defined as
`cmd-?` . Using `cmd-shift-/` instead doesn't work, so we'll likely have
to update `MacKeyboardMapper` to allow mapping between shifted and
unshifted keys equivalent, that is, when `?` is detected, it is able to
determine that, in the user's layout that is the result of `shift-/`.
## Testing
Manually tested, screenshots can be seen in the "Showcase" section.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
## Showcase
<details>
<summary>Before</summary>
<img width="488" height="946" alt="CleanShot 2026-07-03 at 14 24 35@2x"
src="https://github.com/user-attachments/assets/58b0497c-2929-4da3-86b6-a2e0ce0c5ca4"
/>
</details>
<details>
<summary>After</summary>
<img width="524" height="1116" alt="CleanShot 2026-07-03 at 14 24 59@2x"
src="https://github.com/user-attachments/assets/8e2c6320-97ad-4620-b595-182f6d0ded81"
/>
</details>
---
Release Notes:
- Added "Agent Panel" and "Git Panel" items to the "View" menu
# Objective
- Make Git Panel History show commit tags so release/version markers are
visible without opening the full Git graph or commit details.
## Solution
- Store commit history entries with both the commit SHA and tag names
from existing git graph data.
- Render tag names as muted chips next to the commit subject.
- Limit visible tags to 3 per commit and show `+N` for additional tags.
## Testing
- Ran `cargo check -p git_ui`.
- Manually verified on Linux with `script/zed-local --stateful .`.
- Confirmed tags appear in Git Panel History.
## 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
Git Panel History now shows commit tags inline as muted chips next to
the commit subject.
---
Release Notes:
- Added tag labels to the Git Panel commit history.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This PR adds adjustments to the tree view, making it more consistent
with all other tree view displays in the app (e.g., displaying indent
guides, removing chevron toggle, etc.), and also fixes an issue where
the commit message scrollbar was scrolling up with the message.
Release Notes:
- N/A
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.
# Objective
Prevent collapsing a folder in one Git panel section from also
collapsing the same folder path in other sections.
## Solution
Key directory expansion state by `TreeKey`, which includes both the
section and repository path, instead of by `RepoPath` alone. This also
keeps persisted tree state, stale-state cleanup, and selected-file
reveal behavior section-aware.
## Testing
- Added `test_tree_view_directory_expansion_is_scoped_to_section` to
cover the same folder path under Tracked and Untracked independently.
- `cargo fmt -p git_ui -- --check`
- `git diff --check`
- Attempted `cargo test -p git_ui
test_tree_view_directory_expansion_is_scoped_to_section --lib`, but
dependency compilation could not complete because the local disk ran out
of space. Reviewers can run that command to execute the focused
regression test.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Suggested .rules additions
- In the Git panel tree view, key per-row UI state by `TreeKey` rather
than `RepoPath`, because the same directory can appear in multiple
sections.
---
Release Notes:
- Fixed collapsing a folder in one Git panel section also collapsing it
in other sections.
# Objective
Fixes#57766
Allow users to select and copy the text of commit messages from the git
graph details panel.
## Solution
Implements selectable commit message in the detail panel using
`MarkdownElement`s a la `commit_view`.
### Affordances considered and abandoned:
- "copy message" and/or "copy subject" buttons, but the UI here is
already pretty tight and I don't feel confident enough in my design
chops or familiarity with Zed to propose bigger UI changes here.
- Default-collapsed message with expand button, a la `commit_view`. The
use-case of this panel is to get the gist of a commit while moving
somewhat quickly through the graph. One might argue that the subject
line alone is enough for that, but often it isn't and the thought of
having to constantly expand commit messages rather than making the
message immediately visible with scroll felt like it would produce a
repetitious experience.
## Testing
- Adds two unit tests to verify that selection works and is idempotent
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
Video demonstrating the functionality:
https://github.com/user-attachments/assets/b910aaa3-2db2-4da8-904b-21b270677ca9
---
Release Notes:
- Show full commit message as markdown in details panel of the git graph
# Objective
As mentioned in #59514, the git panel currently runs a full `git status`
for checking whether `git` has access to the repository. This was
introduced in #43693 and currently runs on every file save which is
problematic for large repos where `git status` runs a lot of
computation.
## Solution
This PR caches the `git_access` on the git panel such that we don't need
re-check for git access on every file save.
## Testing
I manually verified that the git panel doesn't trigger anymore
unnecessary git status commands.
**main:**
```
2026-06-18T00:04:24+01:00 DEBUG [project::git_store] start recalculating diffs for buffer 4294967643
2026-06-18T00:04:24+01:00 DEBUG [project::git_store] finished recalculating diffs for buffer 4294967643
2026-06-18T00:04:24+01:00 DEBUG [project::git_store] start recalculating diffs for buffer 4294967643
2026-06-18T00:04:24+01:00 DEBUG [project::git_store] finished recalculating diffs for buffer 4294967643
2026-06-18T00:04:24+01:00 DEBUG [project.format.local] formatting buffer '"/Users/lgeiger/code/zed/CONTRIBUTING.md"'
2026-06-18T00:04:24+01:00 DEBUG [project.format.local] no changes made while formatting
2026-06-18T00:04:24+01:00 DEBUG [git::repository] Checking for git status in ["CONTRIBUTING.md"]
2026-06-18T00:04:25+01:00 DEBUG [git::repository] Checking for git status in []
```
```
/opt/homebrew/bin/git -c core.fsmonitor=false -c log.showSignature=false --no-optional-locks --no-pager status --porcelain=v1 --untracked-files=all --no-renames -z -- CONTRIBUTING.md
/opt/homebrew/bin/git -c core.fsmonitor=false -c log.showSignature=false --no-optional-locks --no-pager diff --numstat --no-renames HEAD -- CONTRIBUTING.md
/opt/homebrew/bin/git -c core.fsmonitor=false -c log.showSignature=false --no-optional-locks --no-pager config --get commit.template
/opt/homebrew/bin/git -c core.fsmonitor=false -c log.showSignature=false --no-optional-locks --no-pager status --porcelain=v1 --untracked-files=all --no-renames -z --
```
**This PR:**
```
2026-06-18T02:47:54+01:00 DEBUG [project::git_store] start recalculating diffs for buffer 4294967656
2026-06-18T02:47:54+01:00 DEBUG [project::git_store] finished recalculating diffs for buffer 4294967656
2026-06-18T02:47:55+01:00 DEBUG [project.format.local] formatting buffer '"/Users/lgeiger/code/zed/CONTRIBUTING.md"'
2026-06-18T02:47:55+01:00 DEBUG [project.format.local] no changes made while formatting
2026-06-18T02:47:55+01:00 DEBUG [git::repository] Checking for git status in ["CONTRIBUTING.md"]
```
```
/opt/homebrew/bin/git -c core.fsmonitor=false -c log.showSignature=false --no-optional-locks --no-pager diff --numstat --no-renames HEAD -- CONTRIBUTING.md
/opt/homebrew/bin/git -c core.fsmonitor=false -c log.showSignature=false --no-optional-locks --no-pager status --porcelain=v1 --untracked-files=all --no-renames -z -- CONTRIBUTING.md
/opt/homebrew/bin/git -c core.fsmonitor=false -c log.showSignature=false --no-optional-locks --no-pager config --get commit.template
```
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
/cc @dinocosta
---
Release Notes:
- Improved Git Panel performance by no longer re-checking repository
access on every file change
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
At larger font sizes (e.g. I have profiles that increase the font sizes
when screen sharing) the commit button in the git panel editor does not
stay aligned to the bottom-right of the screen, and overlaps the other
elements:
<details>
<summary>Click to show showcase</summary>
https://github.com/user-attachments/assets/e73034db-07a6-42d7-b993-9d8091e50b70
Notice the extra clipping of the commit message editor element:
<img width="500" alt="image"
src="https://github.com/user-attachments/assets/67d59405-57e2-4547-87c2-1c4728515c26"
/>
</details>
This was happening because the floating icons on the right and the
footer containing the commit button were positioned absolutely, used
pixels instead of responsive rems, and had an offset that was calculated
and did not account for changes in user rem size.
So I've moved things around to be more "flexy"... basically just
removing the absolute positioning and making the elements flush against
one another.
## Testing
I have tested this manually on macOS 27 beta 2 and Windows 11, both
using various light/dark themes, window sizes, commit text, etc.
## 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
Here's a demo at different zoom levels, with and without text, when
expanding the commit window, etc.
<details>
<summary>Click to view showcase</summary>
https://github.com/user-attachments/assets/bea82da1-0c7f-4d51-a73b-d4bc4581a2b7
And here's another demo with debug colors for the different elements to
see what's going on:
https://github.com/user-attachments/assets/12fd3e95-5089-4e34-a84c-c352219ee197
</details>
---
Release Notes:
- Git Panel: Fixed overlapping elements in commit message container
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
When no LLM provider is configured, hovering the disabled "Generate
Commit Message" button in the git panel/commit modal previously showed a
plain, non-interactive tooltip with no way to act on it.
This tooltip now includes two links:
- **Configure Provider** — jumps directly to the "LLM Providers"
settings sub-page.
- **See Docs** — opens `https://zed.dev/docs/ai/llm-providers`.
Also adds `IconButton::hoverable_tooltip`, mirroring the existing
`.tooltip(...)` forwarding, since `IconButton` didn't previously expose
the underlying `ButtonLike::hoverable_tooltip` capability needed for
interactive tooltip content.
Release Notes:
- Improved the commit message tooltip to link directly to LLM provider
settings and documentation when no provider is configured.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This follows up on discussion #56551.
Right now, when Zed generates a commit message, it includes project
rules files like `AGENTS.md`, `CLAUDE.md`, and `.rules` in the prompt
alongside the git diff. That can add a lot of extra context for a task
that is really just summarizing the changes in a commit.
This PR adds an `include_project_rules` option to
`agent.commit_message_model`. When it is set to `false`, Zed skips
loading project rules when generating commit messages. If the option is
omitted, the current behavior stays the same.
Example:
```json
{
"agent": {
"commit_message_model": {
"provider": "anthropic",
"model": "claude-3-5-haiku",
"include_project_rules": false
}
}
}
```
I also updated the settings plumbing so this option is only used for commit message generation and defaults to true when not specified.
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:
- agent: Added setting to exclude project rules files from commit message generation prompts (`agent.commit_message_include_project_rules`)
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
# 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
- Default the solo diff view to show changed hunks with excerpted
context instead of expanding the entire file.
- Closes https://github.com/zed-industries/zed/issues/59489
## Solution
- Initialize the solo diff editor with excerpts around changed hunks.
- Add a header toggle for switching between the excerpted changes-only
view and the full-file view.
- Keep both sides of the split diff visually aligned when excerpts are
collapsed.
## Testing
- `cargo check -p git_ui`
- `cargo test -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
<details>
<summary>Click to view showcase</summary>
Changes-only default view:
<img width="1624" height="1030"
alt="solo_diff_view_new_default_changes_only_view"
src="https://github.com/user-attachments/assets/c6fb937e-8882-415c-8476-b9c3019c152e"
/>
Toggled full-file view:
<img width="1624" height="1030"
alt="solo_diff_view_toggled_to_full_file_view"
src="https://github.com/user-attachments/assets/3d736d00-178a-4dfa-b1ff-d3d15e33b30e"
/>
</details>
---
Release Notes:
- Improved solo diff view to show changed hunks by default with a toggle
for viewing the full file.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
Losing the connection on a remote project, or restarting Zed, while
editing a git commit message cleared the in-progress text, because the
Git panel rebuilds the commit buffer from the repository and discards
unsent input.
This persists the draft, scoped to the active repository's work
directory, in the panel's serialized state and restores it when the
panel is rebuilt from that state: at construction when the active
repository already matches, and again in `reopen_commit_buffer` once the
commit buffer loads. The restore only applies to an empty target buffer
whose work directory matches the active repository, so it never replays
committed or cleared text and never leaks a draft across repositories.
The persisted draft is cleared after a successful commit.
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#47864
Release Notes:
- Fixed in-progress git commit messages being cleared when a remote
project reconnects or Zed restarts
---------
Co-authored-by: Cole Miller <cole@zed.dev>
#59043 updated the project diff and git panel to improve the sorting
options and make the order of files always match across the two.
However, the approach relied on sorting the list of buffers first and
then using an incrementing `PathKey.sort_prefix` to insert them into the
multibuffer. This is a problem because path keys are intended to be
stable, and any addition of removal of a buffer from the multibuffer
would cause the path keys for all subsequent buffers to change, so
`update_path_excerpts` would do unnecessary work.
This PR fixes that by computing stable path keys for the buffers based
on the ordering settings:
- `PathKey.sort_prefix` is based on the git status if that setting is
enabled, or a constant otherwise (the same way it worked before #59043)
- when the tree view is disabled, `PathKey.path` is either the raw
`RepoPath` (if sorting by path) or `{name}/{repo_path}` (if sorting by
name). When the tree view is enabled, we get the path by inserting `\0`
just before every directory component of the `RepoPath`, so that all
directories sort before all files.
Release Notes:
- N/A
Update the focus handle returned by the `GitPanel::focus_handle` method
in order to ensure that, if the commit editor is currently expanded,
using the `git_panel::ToggleFocus` action will correctly focus back on
the expanded editor, rather than on the panel.
# Objective
When using the expanded commit editor, if one focuses away from the
panel and then uses the `git panel: toggle focus` action in order to
focus back on the panel, the focus will land on the panel, which is now
being rendered behind the commit editor.
## Solution
Update the focus handle returned by the `GitPanel` to take into
consideration whether the commit editor is expanded and, in that case,
return the editor's focus handle instead.
## Testing
Tested both manually as well as through a newly introduced test –
`git_ui::git_panel::tests::test_focus_handle`.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
<details>
<summary>Before</summary>
https://github.com/user-attachments/assets/0e2647f3-2835-485f-8f01-2128d2de6b8e
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/cc77fae7-e76c-4389-82b0-f4e7ec8258d7
</details>
---
Release Notes:
- Fixed `git panel: toggle focus` to focus back on the commit editor in
case it is expanded.
# 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.
# Objective
- Keep the Git panel view options menu open when changing view, sort, or
group options.
- Make the open menu reflect the selected option immediately, including
showing the Sort By section as soon as List view is selected.
## Solution
- Use a persistent context menu for the Git panel view options menu so
selecting an item rebuilds the menu instead of dismissing it.
- Track the open menu's view options state locally with
`GitPanelViewOptionsMenuState` so checkmarks and conditional sections
update before the settings file change is observed.
- Continue dispatching the existing Git panel actions so persisted
settings and panel updates keep using the current code path.
## 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
- N/A
---
Release Notes:
- Fixed Git Panel view options menu selections updating only after
reopening the menu.
The recent "pickers with previews" overhaul left the picker
sizing/presentation API spread across several overlapping knobs that
every call site had to set correctly — and many didn't, causing pickers
across the app to render at the wrong width, lose their container, or
stop dismissing. This PR consolidates that surface into a small,
hard-to-misuse API and makes correct sizing the default.
Net effect: a plain `Picker::uniform_list(delegate, …)` now renders
correctly out of the box (standard width, standard max-height, shrinks
to fit, dismisses properly), and the ~35 call sites only specify what
genuinely differs.
## API changes
**Presentation** — three overlapping booleans (`is_modal`, `is_popover`,
`is_resizable`) collapsed into one enum, with resizability living inside
the only variant where it's meaningful:
```rust
enum Presentation {
Modal { resizable: bool }, // own chrome, dismisses on blur, optionally resizable
Popover, // own chrome, dismisses on blur, never resizable
Embedded, // host container owns chrome + dismissal
}
```
- `modal(bool)` is **removed** in favor of explicit, self-documenting
builders:
- *(default)* → `Modal` (resizable iff it has a preview)
- `.popover()` → `Popover` (menu-attached surfaces)
- `.embedded()` → `Embedded` (pickers nested in a larger modal/view)
- Dynamic callers use `.when(cond, Picker::embedded)` (added `impl
FluentBuilder for Picker`).
**Sizing** — preview-vs-not now drives everything; the manual padding
knob is gone:
| Before | After |
|---|---|
| `vertical_padding` field + `no_vertical_padding()` | removed — derived
from whether a preview is visible |
| `height(...)` (ambiguous: fixed vs max) | `max_height(...)` (plain
pickers shrink-to-fit, capped here) |
| `minimum_results_width(...)` | removed — a plain picker's min width
tracks its opening width; preview pickers use standard internal pane
mins |
| default size = 60% viewport | default = `DEFAULT_MODAL_WIDTH` (34rem)
× `DEFAULT_MODAL_MAX_HEIGHT` (24rem, max) |
| resize handles gated on `is_modal` | gated on `is_resizable` (new
`resizable(bool)` builder; auto-`true` for preview pickers) |
Call sites now only override the exceptions: narrow popover selectors
(`initial_width`), the taller outline view (`max_height`), and preview
pickers (constructed via `*_with_preview`).
## Behavior fixes
- **Wrong widths everywhere**: pickers were falling back to
60%-of-viewport because the original migration set
`minimum_results_width` but never `initial_width`. Fixed at the source
via the new defaults.
- **Popovers had no container and wouldn't dismiss**: `is_modal=false`
was suppressing both the elevated background *and* blur-dismiss. Split
out so popovers keep their chrome and dismiss on click-away/escape. This
fixed the agent-panel model/profile selectors, sidebar recent projects,
and the settings theme/font/icon/ollama pickers (which were incorrectly
using `modal(false)`).
- **Sidebar recent projects stretched to full height**: was missing the
shrink-to-fit behavior; now capped and content-sized like other
popovers.
- **Preview crash**: removed an over-strict `debug_assert!` that
panicked when previewing an empty file (`message == None && editor
empty` is valid).
- **Preview-aware default size**: pickers open at standard width with
the preview hidden, and expand to the larger "telescope" size when a
preview is shown. Fixes the text finder rendering super-wide by default,
and makes the file finder expand (rather than cram its results) when you
toggle the preview.
---
Release Notes:
- N/A
Xin Zhao