# 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
Closes#44926Closes#43157Closes#29903
We have an askpass 17s timeout that races against Git operations and
results in "Connecting to host timed out". It came along in #25953 when
we extracted askpass out of remoting, where it was used for SSH.
I think, for SSH connection, no prompt and no connection after 17
seconds means the host is unreachable, so the timeout is a reliable
signal there. But for Git, silence is pretty normal. Cases like hook
running, pack transferring, an ssh-agent waiting on a fingerprint are
all senarios where we should not be dependent on timeout which kills
these healthy operations.
#43285 worked around this for commits by running the pre-commit hook
manually and passing `--no-verify` to `git commit`. But, there are more
problems to address, which I reproduced on my machine:
1. A slow `post-commit` hook fails, since `--no-verify` doesn't skip it.
2. A slow `pre-push` hook fails too, and a workaround like #43285 needs
a lot more handling. See
https://github.com/zed-industries/zed/pull/42946#issuecomment-3550570438.
3. This is the tough one: due to `--no-verify`, we are also skipping the
`commit-msg` hook. There is no direct way to call that hook since, Git
hands this hook its in-progress message file, commits whatever the hook
leaves in it, and aborts if the hook exits non-zero. Reproducing that
outside `git commit` means reimplementing that.
4. An ssh-agent waiting for user approval fails after the timeout, like
if you have 1Password set up.
5. It doesn't solve large fetches. Fetching
`git@github.com:torvalds/linux.git` just dies at the 17s timeout
mid-download.
This PR fix keep the timeout only on the SSH transport and drop it for
Git, which is less of a behavior change and more of a restoring its
original scope. If Git in a terminal doesn't time out, we shouldn't
either. This way, we let Git handle all types of hooks, which solves the
hooks issue along with the timeout issue. _This follows how VS Code does
it. It does not have any kind of timeout on git child process, and hooks
are handled by Git itself._
Edit: I also think working towards way to cancel long going operations
is better way forward. See
https://github.com/microsoft/vscode/issues/171353.
Hooks still don't run for untrusted repositories, the existing
`core.hooksPath=/dev/null` clamp covers that. The `RunGitHook` proto
handler is kept for compatibility with older remote clients.
Release Notes:
- Fixed git operations failing with a misleading "Connecting to host
timed out" error when they took longer than 17 seconds (large fetches,
slow hooks, or waiting on agent-based authentication like 1Password
Touch ID).
- Fixed `commit-msg` hooks being silently skipped on commit.
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 ...
This PR adds support for entering your git GPG passphrase through the
askpass UI. As a daily Zed user I'm really missing this feature, this
forces me to switch to a terminal or an external application. which is
not ideal for me and most people that are forced to use GPG signing.
Right now Zed can show a similar error (redacted) when you are trying to
commit with GPG signing enabled:
```
error: gpg failed to sign the data:
[GNUPG:] KEY_CONSIDERED <redacted> 2
[GNUPG:] BEGIN_SIGNING H8
[GNUPG:] PINENTRY_LAUNCHED 4625 curses 1.3.2 - xterm-ghostty - - 501/20 0
gpg: signing failed: Inappropriate ioctl for device
[GNUPG:] FAILURE sign <redacted>
gpg: signing failed: Inappropriate ioctl for device
fatal: failed to write commit object
```
Here is the key configurion parts of my **global** git config:
```
[user]
name = Remco Smits
email = <redacted>
signingkey = <redacted>
[commit]
gpgsign = true
[tag]
gpgsign = true
```
**Before**
https://github.com/user-attachments/assets/60a06574-92f1-45df-a29a-8ae11db6751d
**After**
https://github.com/user-attachments/assets/92b648e9-b538-4ce5-af4c-136689d14e1a
**How to test this?**
1. Create a key `gpg --full-generate-key`
2. Run `git config --global user.signingkey <KEY ID>`
3. Run `git config --global commit.gpgsign true`
4. Run & copy result from `gpg --armor --export <KEY ID>` and submit
your public key to github
[https://github.com/settings/gpg/new](https://github.com/settings/gpg/new)
5. Make a change and try committing
6. See that it promts for your passphrase :)
**Note**: I used AI as an assistant to write this PR
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Git: Passphrase prompts from GPG to unlock commit signing keys are now
shown in Zed.
Co-authored-by: Lukas Wirth <lukas@zed.dev>
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>
## Objective
Fix Git Graph showing `0 Changed Files` for commits that modify
submodules.
This happened because submodule entries are gitlinks rather than regular
blobs, so the existing commit diff loading path could not resolve them
correctly.
I ran into this issue previously, and it was confusing because the
commit clearly contained changes, but the UI did not reflect them. If a
commit included many file changes plus a submodule update, the submodule
change was effectively hidden and the UI could still show `0 Changed
Files` for that entry. Since submodules are not used in every
repository, the bug is easy to miss and may go unnoticed for a long
time.
## Solution
- Switched commit diff loading to use Git's raw diff output so submodule
entries are represented explicitly.
- Added parsing for gitlink entries alongside regular file changes.
- Render submodule changes as `Subproject commit <oid>` so they show up
in commit diffs instead of being dropped.
## Testing
- Added a repository test covering commit diffs that include submodule
changes.
- Ran the `git` crate test suite.
- Ran formatting and lint checks.
- Verified the Git UI crate still builds.
- Ran and tested it locally on MacOS.
Reviewer notes:
- The change is limited to commit diff loading and should not affect
normal blob diffs.
- Submodule changes now appear as explicit entries instead of being
counted as zero files.
## 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="200" alt="Screenshot 2026-07-06 at 19 22 57"
src="https://github.com/user-attachments/assets/16efc348-5909-4cb0-8589-b0662923df56"
/>
After:
<img width="200" alt="Screenshot 2026-07-06 at 20 20 11"
src="https://github.com/user-attachments/assets/3201b264-6e61-45de-a9fc-c585f3b54e09"
/>
<img width="200" alt="Screenshot 2026-07-06 at 20 37 57"
src="https://github.com/user-attachments/assets/182ed4e1-9e90-4e33-9136-7626aba31153"
/>
---
Release Notes:
- Fixed Git Graph showing `0 Changed Files` for commits that update
submodules.
On Linux and FreeBSD the native file watcher is non-recursive, so a
watch on the .git directory itself does not report changes to files
nested below it. Loose refs live in nested directories under refs, so
external git commit, fetch, branch, and update-ref operations that don't
also touch a direct child of .git (like the index) went entirely
unnoticed.
Watch every directory in the refs tree when a repository is inserted,
and watch directories subsequently created under refs (new remotes,
slash-named branches) as their creation events arrive. On platforms with
recursive watchers these registrations dedupe against the existing
recursive watch, making them free.
---
Release Notes:
- N/A or Added/Fixed/Improved ...
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>
# Objective
Whenever the git repository state is updated on disk (e.g., via staging,
committing, branch switching, or stashing), `reload_buffer_diff_bases`
is scheduled to reload the diff for all active buffers. This causes 2
git processes to be spawned for each open file which can become
noticeable when many files are open
5e32405669/crates/project/src/git_store.rs (L5179)
## Solution
This PR introduces `load_revisions` which uses a single `git cat-file
--batch` command to compute the diff for all files in the same git
process. This prevents the need to sequentially schedule 2 git
subprocesses per open buffer.
I also changed `load_index_text` and `load_commited_text` to rely on
`load_revisions` which simplifies the code.
## Testing
I added a unittest and manually verified that Zed now only runs a single
`git cat-file --batch` command instead of 2 `git show` processes per
open buffer.
On macOS I viewed the currently running git processes using:
```shell
sudo eslogger exec | jq --unbuffered -r '
select(.event.exec?.target?.executable?.path? | strings | contains("git")) |
(.event.exec?.args? // []) | join(" ")
'
```
## 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 @Veykril
Release Notes:
- Reduced number of git processes for calculating diff of open buffers
when the repo state changes on disk
# Objective
Zed ignores files marked by Git as type-changed (T), causing commits
containing only these changes to show 0 Changed Files.
For example, commit d7cc949e61 changes
crates/eval_utils/LICENSE-GPL from a regular file to a symlink, but Zed
displays no changes.
## Solution
Handle TypeChanged files like modified files by loading both their old
and new contents.
## Testing
- Added parser coverage for the T status.
- Added a repository test for a regular-file-to-symlink change.
- Ran cargo test -p git.
- Ran ./script/clippy -p git.
- Manually verified the example commit on macOS.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content 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="200" alt="image"
src="https://github.com/user-attachments/assets/277c5938-5c2c-47b7-902d-9061a14c062a"
/>
After:
<img width="200" alt="image"
src="https://github.com/user-attachments/assets/f99d0005-0712-4843-814e-d73b11f64782"
/>
———
Release Notes:
- Fixed type-changed files not appearing in Git Graph and commit views.
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
Remote `HEAD` refs such as `origin/HEAD` and `upstream/HEAD` are
symbolic refs that point to a remote's default branch. These refs can
appear in the branch picker, but selecting them shows this error prompt:
This happens because the local branch name is directly derived from the
selected ref, resulting in an attempted checkout of a local branch named
`HEAD`.
This change follows up on feedback from #57588, which just filtered
remote `HEAD` refs out of the branch picker to prevent the error prompt.
As mentioned in [this
comment](https://github.com/zed-industries/zed/pull/57588#issuecomment-4533477336),
I agree that the preferred behaviour should be to instead allow checking
them out - useful for repos with multiple remotes such as an upstream.
For example, if `refs/remotes/origin/HEAD` points to
`refs/remotes/origin/main`, selecting `origin/HEAD` now behaves like
selecting `origin/main`, switching to the corresponding local `main`
branch instead of trying to create or check out a branch named `HEAD`.
This does not fetch or pull from the remote; it uses the locally known
remote refs.
Release Notes:
- Fixed selecting remote HEAD refs from the branch picker
---------
Co-authored-by: Smit Barmase <heysmitbarmase@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.
## Summary
- Allows Git Graph search to match abbreviated or full commit hashes
when the query looks like a SHA.
- Keeps the existing message search behavior for non-hash queries.
- Mirrors the hash search heuristic in the fake git backend and adds
GPUI coverage for hash and message search.
<img width="1912" height="1241" alt="image"
src="https://github.com/user-attachments/assets/903b438e-baa8-4447-95dc-faf321bca6a5"
/>
## Test Plan
- `cargo fmt --check --package git_ui`
- `cargo -q test -p git_ui
test_git_graph_search_matches_commit_hash_prefix -- --nocapture`
- `./script/clippy -p git_ui`
## Suggested .rules additions
- N/A
Release Notes:
- Improved Git Graph search to find commits by abbreviated or full hash.
# Objective
The scp-style remote rewrite only treats a leading `user@` as SSH when
the username matches `^[0-9a-zA-Z\-_]+@`. Remotes like
`first.last@host:owner/repo.git` (common on self-hosted instances that
authenticate as the developer) therefore fail to parse, so no hosting
provider matches and Copy Permalink, git blame links, and Open in
browser silently break. Extends #21508, which added `org-000000@`.
## Solution
Match the scp username by exclusion (`^[^/@:]+@`): anything before the
`@` that isn't the `:`/`/` delimiting host and path, mirroring git's scp
syntax. The pattern stays anchored, so `scheme://user@host` URLs aren't
misclassified, and it's a strict superset of the old one, so existing
remotes are unaffected.
## Testing
`cargo test -p git` passes, including two new
`test_parsing_valid_remote_urls` cases — a dotted-username scp remote
(the fix) and a `https://user@host` regression guard. `cargo fmt` and
`cargo clippy -p git` are clean.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed detection of SSH git remotes whose username contains characters
such as `.` (e.g. `first.last@host:owner/repo.git`), which previously
broke permalinks, git blame links, and "open in browser".
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
# Objective
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 switches to a simple `git rev-parse` command which is cheap and
achieves the same goal.
## Testing
I added a unittest.
## 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:
- Improve performance of git access checks in git panel
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.
# Objective
When reviewing changes in the Git Panel, the only ways to open a file
were through a diff view ("Open Diff" or "Open Diff (File)"). There was
no way to open the file directly in the editor to inspect or edit its
current contents without entering a diff.
This PR adds a **View File** action to the Git Panel changes list
context menu.
## Solution
- Add a `git::ViewFile` action in `crates/git/src/git.rs`, alongside
other per-file git actions like `FileHistory`.
- Wire it into the Git Panel file context menu, between the diff actions
and "View File History".
- Implement `GitPanel::view_file` to resolve the selected entry's repo
path to a project path and open it via `workspace.open_path_preview`,
matching the pattern used in `commit_view::open_file_at_head`.
- Document the new action in `docs/src/git.md`.
### Related issues
- https://github.com/zed-industries/zed/issues/58250
## Testing
- Added three GPUI tests in `git_panel.rs`:
- `test_view_file_tracked` — modified tracked file
- `test_view_file_untracked` — untracked file
- `test_view_file_tree_view` — nested file in tree view
- Ran `cargo test -p git_ui test_view_file` — all three pass.
- Ran `./script/clippy -p git_ui` — clean.
**Manual testing for reviewers:**
1. Open a project with changed files and open the Git Panel.
2. Right-click a changed file and select **View File**.
3. Confirm the file opens in the editor (not a diff view).
4. Repeat for an untracked file and with tree view enabled.
5. Confirm **Open Diff** and **Open Diff (File)** still work.
Tested on macOS only. Linux and Windows should behave the same since
this is a context menu action with no platform-specific code, but I
haven't verified on those platforms.
## 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
<details>
<summary>Click to view showcase</summary>
Video recoding of the Git Panel context menu showing the new **View
File** item:
https://github.com/user-attachments/assets/c878fd4d-9acb-4c05-bd91-b452da0a6b90
</details>
---
Release Notes:
- Added "View File" to the Git Panel context menu to open a changed file
in the editor without a diff view.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
When uncommiting we check whether the commit already exists on a remote
branch. This currently spawns a lot of git processes to do so,
especially when having multiple remotes.
This PR switches this to a single `git for-each-ref` call to do the same
checks. I tested this in the UI and added some unit tests to verify this
behaviour.
This is a followup on #59053, #59044 and #59042 with the goal to reduce
overhead of the git handling.
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:
- Improved performance of git uncommit
Retrieving the default branch currently spawns up to 5 git processes
sequentially which isn't ideal.
This PR switches to a `git for-each-ref` and `git config` call to do the
same checks while requiring spawning less git processes. I tested this
in the UI and added a unit test to verify that the behaviour doesn't
change.
This PR follows the approach from #59069.
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:
- Improved performance of retrieving default git branch
Currently Zed fetches remote URLs by sequentially calling `git remote
get-url origin` and `git remote get-url upstream`.
This PR introduces a new `remote_urls` function which uses `git remote
-v` to retrieve all remote fetch URLs with a single git process.
Followup on #59042 and #59042 in the hope to reduce the amount of
spawned git processes.
Probably best to review both commits separately.
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:
- Improved performance of listing git remotes
This is an unsolicited contribution, I hope that's ok. The feature is
small and I didn't want to open a discussion just for this.
There was no way to write to `.git/info/exclude` from Zed, so I added
one.
The "Add to .gitignore" action in the project panel and git panel
context menus is now grouped under a "Git" submenu, with a new "Add to
.git/info/exclude" action next to it.
Both actions:
- skip the write if the pattern is already there
- make sure there's a trailing newline
- show an error toast if something goes wrong
- fail gracefully on remote repositories
In the git panel both entries are disabled unless the file is untracked,
same as the gitignore action was before.
The write logic is shared via a small private helper, covered by two
unit tests.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added `Add to .git/info/exclude` option under a new `Git` submenu in
the project panel and git panel context menus, alongside the existing
`Add to .gitignore` action.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
On Windows, Zed generated a .ps1 askpass script and set **SSH_ASKPASS**
to 'powershell.exe -ExecutionPolicy Bypass -File ...'. SSH calls exec()
on SSH_ASKPASS which cannot exec a command string, causing:
error: ssh_askpass: exec(powershell.exe ...): No such file or directory
Fix by pointing **SSH_ASKPASS** directly to cli.exe and passing the
socket path via **ZED_ASKPASS_SOCKET** env var, which cli.exe reads
before clap parses arguments.
---
> Compiling Zed almost blew up my computer.
---
Related #29048
Release Notes:
- Fixed some ssh issues on windows that prevented from connecting to a
remote
Parse git blame stdout incrementally while the process is still running
instead of waiting for child output to buffer the entire command result.
Release Notes:
- N/A or Added/Fixed/Improved ...
The regression introduced in #53453 where selecting a remote branch from
the branch picker checked out the remote tracking ref directly, leaving
the repository in detached HEAD state. Instead of creating a local
branch that set the remote branch as it's upstream.
The fix was reverting the old checks we did before #53452 was merged to
figure out if the branch was valid, remote only, local, or local without
the upstream set. Depending on the type of reference it is Zed will
check it out, or create/set the branch with remote tracking to its
upstream branch.
I also added a regression test to prevent this from happening again in
the future
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
## Summary
- Remove the `git2` crate and its C dependencies (`libgit2-sys`,
`libz-sys`), replacing all remaining usage with the git CLI and other
previously used rust crates
- Replace `git2::Patch` in `buffer_diff` with `imara-diff` (used
elsewhere in the codebase for word diffing)
- Replace `git2::Oid` with `[u8; 20]` and the `hex` crate
- Replace `git2::Repository` in `RealGitRepository` with stored paths
and git CLI calls via the existing `GitBinary`
- Fixes a bug where linked worktree git dir events could cause the
repository entry to be dropped
### Motivation
libgit2 does not support the
[reftable](https://github.blog/2024-04-29-highlights-from-git-2-45/#preliminary-reftable-support)
storage format that was introduced in git 2.45 (see
[libgit2#7117](https://github.com/libgit2/libgit2/pull/7117)), meaning
that git operations in the app using these (like git status, branch
names, diffs, e.g.) appeared broken for any repository using
`--ref-format=reftable`. [Git 3 will use reftables by
default](https://www.deployhq.com/blog/git-3-0-on-the-horizon-what-git-users-need-to-know-about-the-next-major-release),
so this needs to be supported eventually.
Most operations used the git binary already, but there were still a
handfull of stragglers using libgit2. By swapping out the remaining
uses, we can remove the dependancy of libgit2 and eliminate ~30k lines
of vendored C and the associated build complexity (cmake, libz,
pkg-config), as well as ensure that all git operations go through
similar codepaths.
Closes#46747
Closes https://github.com/zed-industries/zed/discussions/45702
fixes ZED-76X
fixes ZED-73N
### Notes
- `reload_index` is removed from the `GitRepository` trait since both
implementations were no-ops (the CLI always reads from disk)
- `change_branch` is simplified to `git checkout <name>`, which natively
handles local/remote branch resolution
- `load_index_text` and `load_committed_text` no longer explicitly
filter symlinks (the old code returned `None` for symlinked entries)
## Test plan
- [x] `cargo test -p git` (34 tests)
- [x] `cargo test -p buffer_diff` (14 tests)
- [x] `cargo test -p worktree --
test_linked_worktree_git_dir_events_do_not_panic`
- [x] `cargo test -p util` (108 tests)
- [x] `cargo test -p project -- test_file_status
test_repository_subfolder_git_status test_update_gitignore`
- [ ] Manual testing of diff gutter, staging, branch switching, remote
operations
- [ ] Manual testing with a reftable repository
Release Notes:
- Fixed git integration not working with repositories using the reftable
reference storage format
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
Extraction done from #53453
I removed the default Oid implementation we had and added support back
for SHA264 back as well. I also removed the hex dependency and just
added some of those functions we needed in house so we can avoid
building yet another dependency
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
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
My second take on uncluttering the git graph after #53692, this time by
simply replacing `git log --all` with `git log --ignore-missing
--branches --remotes --tags HEAD`. Thanks @JonGretar for educating me on
this 🙂
This pretty much mirrors which commits VSCode's built-in git graph shows
when selecting "All history item references" (though VSCode has an extra
`git for-each-ref` step):
341ef7db2e/extensions/git/src/git.ts (L1280-L1344)
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:
- Git Graph: Now excludes commits that aren't reachable from branches or
tags.
Many projects are switching to main as the default branch name. Prefer
it over master, in case both are present.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
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 (didn't add new test for
parsing SHA-256 - not sure if would be desired)
- [x] Performance impact has been considered and is acceptable
Closes#24070
Upgrades git2 from 0.20.1 to 0.21.0 with the `unstable-sha256` feature -
adds ability to open and work with git repositories using the SHA-256
object format. `Oid::from_str` now detects 64-char hex strings to parse
SHA-256 OIDs correctly.
Also adapts to breaking API changes in 0.21.0:
`Remote::url()` and `Commit::message()` both now return `Result`.
Release Notes:
- Added support for opening SHA-256 object format git repositories
This PR changes the git store's `compute_snapshot`, which runs to update
state that depends on the contents of `.git`, to degrade gracefully when
fetching individual pieces of state fails. For example, when fetching
the list of branches fails, instead of returning early from the function
(leaving the previous git state snapshot in place with stale state), we
continue with an empty list of branches. This prevents failures of
individual git commands from making the entire git UI get stuck
indefinitely.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- Fixed an issue where failing to fetch branches using the git CLI would
prevent other git-related state from being updated.
cc @cole-miller
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 branch enumeration when a broken Git ref prevents commit
metadata from being read.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#53604.
When `log.showSignature = true`, git prepends signature verification
lines to stdout before the `--format` output. The null-separated parsers
in `crates/git/src/repository.rs` weren't expecting that, so SHAs ended
up corrupted — the git graph detail panel showed "0 changed files" for
every commit, and file history was similarly broken.
Setting `-c log.showSignature=false` in `build_command` is the same
trick we already use for `core.fsmonitor`. It only affects
log/show/whatchanged, so other commands aren't touched.
Verified locally with an SSH-signed repo: before this change the detail
panel said "0 changed files"; after, the modified files show up
correctly.
Release Notes:
- git_graph: Fix breakage that occurs when `log.showSignature` is
enabled
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
Git's `-d` flag deletes a branch only if it's fully merged into its
upstream or HEAD - this is what we were using before, which caused the
"not fully merged" error. The `-D` flag force deletes a branch even with
unmerged changes (equivalent to `--delete --force`).
### Before
Deleting an unmerged branch failed with a "not fully merged" error
toast.
### After
- Deleting an unmerged branch prompts for confirmation to force delete
- Delete button tooltip shows "Hold alt to force delete" hint
- Holding **alt** turns the delete icon red and tooltip changes to
"Force Delete Branch"
- Force delete keybinding: `cmd-alt-shift-backspace`
Release Notes:
- Added confirmation prompt when deleting unmerged git branches, with
option to force delete.
- Added alt+click on delete button to force delete a branch immediately.
## Summary
Fixes the `git: worktree` popup showing no worktrees when a project is
opened at the parent of a `.bare` directory (the common
bare-clone-with-sibling-worktrees layout).
## What's fixed
- `crates/git/src/repository.rs`
- New `git_binary_for_worktree_list` helper that uses
`repository.path()` as the working directory when `workdir()` is `None`.
- `worktrees()` switched to the new helper.
- `parse_worktrees_from_str` accepts bare entries without a `HEAD` line.
- Tests
- Unit test: parser handles a bare entry with no `HEAD` followed by a
normal worktree entry.
- Integration test: full `.git`-file → `.bare` + sibling worktrees
layout (`main`, `feature-a`, `feature-b`) is listed correctly via the
real `git` binary.
UI rendering already gates on empty sha (`worktree_picker.rs` uses
`.when(!sha.is_empty(), ...)`), so the bare entry's empty sha renders
without artifacts.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments — N/A, no `unsafe`
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable — same
single `git worktree list --porcelain` invocation, no extra work
#### Closes#54824
Video
[Screencast from 2026-04-28
09-43-45.webm](https://github.com/user-attachments/assets/e414d546-eb61-4cb2-857e-3c392f416f96)
Release Notes:
- Fixed the `git: worktree` popup listing no worktrees when a project
was opened at the parent of a `.bare` directory
(bare-clone-with-sibling-worktrees layout).
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
* Perform grouping even for repositories that have no main worktree
* Enable grouping for remote projects
* Delete entire project groups when deleting via the recent project
picker
Release Notes:
- Fixed a bug where each linked worktree appeared as its own entry in
recent projects for repositories without main worktrees
- Fixed a bug where deleting projects from the recent projects sometimes
appeared to have no effect.
Allows using the "View history" functionality also on folders and the
project root, and not only on files.
Renamed "View file history" to "View history" in the context menu to
make it consistent.
<img width="1740" height="769" alt="project_history"
src="https://github.com/user-attachments/assets/7f7f8115-6160-44f5-868f-69ac942df8e4"
/>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added git history for folders and whole project
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
Fixes https://github.com/zed-industries/zed/issues/54830
This fixes a bugs where
* when there's no main worktree, we treated the first linked worktree as
main
* the titlebar and sidebar showed two different things when opening a
linked wortree directly
When there's no main worktree, our "project group key" will be the bare
repo path. For displaying this to the user, we try to present something
meaningful:
* If the bare repo is `foo.git`, we'll say "foo"
* If the bare repo is "bar/.bare", we'll "bar"
Release Notes:
- Fixed bugs in Zed's sidebar and titlebar when editing in git worktrees
created from bare repositories.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
Using the existing commit editor in the Git Panel to type out longer
commit messages has been somewhat hard. I believe this happens because
it takes a very small portion of the UI which, unfortunately, when `git:
expand commit editor` is used, a modal ends up taking the center of the
editor, making it possible to have the commit editor open on the side,
while the `git: diff` view is open.
As such, this Pull Request introduces a new
`git::ToggleFillCommitEditor` action that allows users to update the
commit editor's height so as to take as much vertical space as possible,
hiding the entries status and simply rendering the Git Panel's footer.
This makes it easier to be able to write longer commit messages while
still having the `git: branch diff` on the side, something that's very
complicated with the default number of lines in the commit editor and
impossible using the `CommitModal`.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added a `git::ToggleFillCommitEditor` action that expands the commit
editor to fill the git panel's available vertical space.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Danilo Leal <67129314+danilo-leal@users.noreply.github.com>
## Summary
This PR replaces the git file history view with the git graph view that
doesn't render the graph canvas. This has several advantages
1. Benefits from the graphs performance and lazy loading
2. Gets the graph's search for free
3. Resizable columns
4. The commit information panel
5. Is persistent
6. Cleans up a lot of code
The one con of this change is the graph doesn't have support
remote/collab support yet, but that is a WIP and should be merged within
a week.
Also, the git graph now propagates errors to the UI, which is the last
thing on the graph's stable launch todo list!
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Joseph T. Lyons <JosephTLyons@gmail.com>
I frequently use the branch name copy action in GitHub Desktop.
I want to do this in Zed.
Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
- [X] Unsafe blocks (if any) have justifying comments
- [X] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [X] Performance impact has been considered and is acceptable
Release Notes:
- Added a `git: copy branch name` action.
### Motivation
To support remote Git graph usage, we need remote support for the Git
APIs that the graph depends on. This PR adds remote support for
`CommitDataHandler` (the `git cat-file --batch` process manager),
allowing remote Git graph consumers to fetch visible commit data without
polling.
#### Summary
The Git graph separates the UI and data layers so the UI can continue
rendering while commit data is fetched in the background. This change
extends that model to remote repositories by allowing
`GitStore::fetch_commit_data(sha: Oid, await_result: bool, cx: &mut
Context) -> &CommitDataState` to await remote commit loading.
For simplicity, the `Starting` variant was removed from
`CommitDataState`. `CommitDataState::Loading(Option<...>)` now stores
`Some(...)` when `await_result == true` is passed to
`fetch_commit_data`. This allows the data layer to await commit loading
without polling, and only when explicitly requested.
I also removed the `Graph` prefix from `CommitData`-related types
because this API is general-purpose and not limited to the graph. Longer
term, I hope to replace `Repository::show` with the commit data
functionality, since it already provides built-in caching.
#### Bug Fixes
- Fix stale `Loading(...)` entries that survive enqueue failure or
handler shutdown.
- Fix commit data handler bookkeeping so `pending_requests`,
`completion_senders`, and `CommitDataState` remain consistent.
- Fix remote commit-data loading so the data layer can await results
instead of polling.
#### Testing
- Add property tests for commit data fetching.
- Add a collab integration test that verifies batched remote commit-data
fetching.
#### Follow Up
In a follow-up, I want to replace the `Repository::show` backend with
the commit data handler and remove `CommitDetails` from the codebase as
a cleanup and maintenance pass. The commit data handler already provides
caching and is a better long-term path for commit metadata access.
I may also want to allow the `CommitData` type to propagate errors to
callers.
For the Git graph, the remaining work is remote search and initial data
fetching.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
adds a 'git: view commit' – accepting a ref (e.g. HEAD, an sha, etc) to
more easily navigate to the git commit view.
<img width="3024" height="1888" alt="Screenshot 2025-09-26 at 21 43
09@2x"
src="https://github.com/user-attachments/assets/c001baec-66c2-46e5-b4a7-f691631f4166"
/>
if a bad ref is entered, the user is shown a generic error
<img width="2734" height="1442" alt="Screenshot 2025-09-27 at 21 04
52@2x"
src="https://github.com/user-attachments/assets/abdbd92d-ef0b-4de9-afb9-e9e52607dfdd"
/>
happy to adjust any of that. also worth noting is the `git: branch`
command UI is a bit nicer, can e.g. show you some metadata on the commit
before you select it, so happy to take it further in that direction if
desired, but thought i'd keep it simple to start.
Release Notes:
- Added view commit command palette action
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
- Don't ever swap to the ellipsis menu with the close icon button; we
now always have it
- Promote the "focus the last workspace" feature through the ellipsis
menu
- Add a unified tooltip for the thread item to show relevant thread
metadata
- Use a different icon for accessing the now "all threads" view
- Simplifies how we display archived threads
- Bonus: Don't display the "open in new window" button in currently
active worktrees (in dedicated picker)
- Bonus: Use the "main worktree" label for whenever we're mentioning the
original worktree
Release Notes:
- N/A
