255880598d46c5cc299b9d762dbc4e619002af03
389
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
f652da59e8 |
Added Tracked , Staged options to stash (#62254)
# Objective Closes #62252 The Git Panel could only stash *everything* — `Stash All` runs `git stash push --include-untracked`, sweeping tracked edits and untracked files into a single entry. There was no way to stash a subset, so the common workflows of "park my tracked edits but keep my new scratch files" and "park what I've staged and keep working on the rest" required dropping to the terminal. ## Images <img width="389" height="358" alt="Screenshot 2026-08-10 at 3 10 50 PM" src="https://github.com/user-attachments/assets/18e4c943-e320-4802-ada8-59e54bf4cefd" /> <img width="504" height="462" alt="Screenshot 2026-08-10 at 3 10 37 PM" src="https://github.com/user-attachments/assets/783237eb-980d-47bc-a0f5-17b03a23a60c" /> ## Solution Add two stash variants alongside `Stash All`, surfaced in the Git Panel's overflow menu based on how the list is currently grouped, so the menu mirrors the sections the user can actually see: | Group By | Stash entries offered | | --- | --- | | None | Stash All | | Tracked & Untracked | Stash All, **Stash Tracked** | | Staged & Unstaged | Stash All, **Stash Staged** | - **`git::StashTracked`** stashes tracked changes and leaves untracked files in place. It reuses the existing pathspec plumbing (`Repository::stash_entries`), filtering the status list down to the paths to stash. - **`git::StashStaged`** stashes the index only, leaving unstaged changes in place. This *cannot* be expressed as a pathspec — a partially staged file would have its unstaged hunks stashed too — so it needs git's own `--staged` flag. That meant a new `GitRepository::stash_staged` backend method and an `optional bool staged` field on `proto::Stash` so remote projects work too. Both actions are unbound by default and are dispatchable from the command palette when the panel is focused. One subtlety worth calling out for review: `Stash Tracked` filters on `FileStatus::is_created()`, not `is_untracked()`. Staging a new file flips it from `Untracked` to `Tracked { Added }`, but the panel still lists it under **Untracked** — using `is_untracked()` meant staged-new files were silently stashed. `is_created()` is the same predicate the panel uses to build that section (`git_panel.rs`), so the menu item and the list can no longer disagree. This branch also includes a separate commit adding **per-section staging** (`git::StageSection` / `git::UnstageSection`) — right-click a file to stage or unstage every entry in its section. Happy to split that into its own PR if preferred. ## Testing Manually tested on macOS against a scratch repo with a mix of states: modified tracked files, untracked files, and untracked files that had been staged. - `Stash Tracked` with tracked edits + untracked files → only tracked edits stashed; untracked files remain. - `Stash Tracked` with untracked files **staged** → they remain, staged. This was broken in an earlier revision and drove the `is_created()` fix above. - `Stash Staged` with one file staged and another modified-but-unstaged → only the staged file is stashed; the unstaged edit and untracked files survive. - `Stash Pop` round-trips both cases back to the original state, with no conflicts. - Menu contents and disabled states verified in all three Group By modes. - Per-section staging covered by a new unit test, `test_stage_section_scopes_to_selected_section`. Not covered by automated tests: the stash actions themselves. `FakeGitRepository` leaves every stash method `unimplemented!()`, so stash behavior isn't reachable from GPUI tests today — consistent with the existing untested `StashAll`. Adding fake-repo stash support looks like a worthwhile follow-up but felt out of scope here. Reviewers on non-macOS platforms: nothing here is platform-specific. Note that `Stash Staged` requires **git 2.35+** (Jan 2022) for `git stash push --staged`; older git surfaces a clear error toast rather than failing opaquely. The remote path (`proto::Stash.staged`) has not been exercised against a live collab session. ## 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 ([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: - Added `Stash Tracked` and `Stash Staged` options to the Git Panel, letting you stash only tracked changes or only staged changes. --------- Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com> |
||
|
|
75c80abb31 |
git: Decode non-UTF-8 blobs for project diffs (#60821)
## Summary Fixes #56449. Related to #16965. Zed’s Git panel and Project Diff build UI diffs from `language::Buffer` diff bases loaded through the Git backend. Git blob loading previously converted bytes with `String::from_utf8(...).ok()`, so legacy-encoded blobs were treated as missing and the whole worktree file appeared newly added. This follows the same encoding path used for worktree buffers: - move shared byte decoding and encoding into `language` - keep Git blob, revision, and index APIs byte-oriented with `Vec<u8>` - decode diff bases and index contents in `GitStore`, where `language::Buffer`s are created - encode index writes using the open buffer’s encoding and BOM so partial staging does not rewrite the file as UTF-8 - keep worktree loading and saving on the same shared implementation Regression coverage includes Windows-1251 decoding/encoding, UTF-8/UTF-16 BOM preservation, raw Windows-1251 Git blob loading, and a `BufferDiffSnapshot` assertion that a one-line CP1251 edit produces one modified-line hunk instead of a full-file rewrite. This does not run Git `textconv` commands. It fixes the reported legacy-encoding case without executing repository-configured commands or modifying working files on disk. ## Testing - `cargo test -p language file_content::tests --locked` - `cargo test -p git repository::tests::test_load_revisions --locked` - `CARGO_INCREMENTAL=0 cargo test -p project git_store::tests::test_decode_git_text_windows_1251_one_line_change --locked` - `CARGO_INCREMENTAL=0 cargo test -p project --test integration test_restaging_hunk_after_optimistic_unstage --locked` - `CARGO_INCREMENTAL=0 cargo check -p project --tests --locked` - `CARGO_INCREMENTAL=0 cargo check -p git_ui --tests --locked` - `cargo fmt --all --check` - `git diff --check` ## Suggested .rules additions - N/A Release Notes: - Fixed Git panel and Project Diff rendering for legacy-encoded text files whose Git blobs are not valid UTF-8. --------- Co-authored-by: Cole Miller <cole@zed.dev> |
||
|
|
c1dab7a0d3 |
Support blaming parent revisions (#62614)
Closes https://github.com/zed-industries/zed/discussions/42583 Adds more tooltip entries and `editor::BlameRevision`, `editor::BlamePreviousRevision` actions to use. Started to highlight gutter blame entries that belong to currently annotated commit. https://github.com/user-attachments/assets/ba754e0b-6431-407c-8d79-2f8b0324fde1 Release Notes: - Supported blaming parent revisions |
||
|
|
1d8ba864ae |
Add optional message support to git stash (#62439)
Show a modal when invoking the stash action to allow users to provide an optional custom message for the stash entry. Closes #62430 # Image <img width="1622" height="1106" alt="Screenshot 2026-08-10 at 9 14 00 PM" src="https://github.com/user-attachments/assets/0d26dac2-919d-4bb1-b6a7-433ceff18955" /> <img width="1622" height="1106" alt="Screenshot 2026-08-10 at 9 14 11 PM" src="https://github.com/user-attachments/assets/896b68ff-999f-4ec9-a6a4-e0e7a6867286" /> # Objective Zed's stash action runs `git stash push --quiet --include-untracked --` with no `-m`, so every stash is labelled with git's auto-generated `WIP on <branch>: <sha> <subject>`. That text describes the commit you were sitting on, not what you stashed — so two stashes taken from the same commit are indistinguishable. This undercuts the stash picker (`git::ViewStash`), which lists entries as `#<index>: <message>` and fuzzy-searches over exactly that string. The search box already exists; there is just nothing meaningful to search, because every candidate is a variation of the same auto-generated line. ## Solution `git::StashAll` now opens a single-line modal ("Optionally provide a stash message") before stashing. - Confirming with text passes `--message <text>` to `git stash push`. - Confirming with the field empty omits the flag entirely, keeping git's default description — so the prompt is a one-keystroke pass-through and existing muscle memory still works. - Cancelling aborts the stash, so the prompt doubles as a confirmation step. Implementation: - `StashMessageModal` (`Editor::single_line`) in `git_panel.rs`, toggled from `GitPanel::stash_all`. `menu::Confirm` trims the input and maps empty to `None`. - `message: Option<String>` threaded through `Repository::stash_all` → `stash_entries` → `GitRepository::stash_paths`. The flag is appended before the `--` separator so a message is never parsed as a pathspec. - New `message` field on the `Stash` proto message, so remote and collab projects behave identically. One non-obvious detail: the modal is opened via `cx.defer_in` rather than inline. `git::StashAll` is registered on the workspace (`git_ui.rs`) as well as on the panel element, and `Workspace::register_action` dispatches while `Workspace` is leased — so opening the modal inline re-enters that update and hits GPUI's `double_lease_panic`. This only reproduces when focus is *outside* the Git Panel, which makes it easy to miss. `Option<String>` rather than `String` is deliberate: `--message ""` produces a blank stash description, which is strictly worse than git's default. ## Testing Manually verified the modal in a local build on macOS: the prompt appears on `git::StashAll`, accepts a message, and the named entry shows up in the stash picker. Also verified at the git level by replaying the exact argument vector `stash_paths` builds against a scratch repo with mixed staged / unstaged / untracked changes: | Case | Result | |---|---| | `stash push --quiet --include-untracked --message "my named stash" -- <paths>` | `stash@{0}: my named stash`; worktree clean, untracked file included | | same, without `--message` | `stash@{0}: <sha> <subject>` — git's default text | | `--message "x" --` with no paths (clean repo) | exit 0, no stash created — the empty pathspec does **not** stash everything | `cargo fmt --check` clean, `./script/clippy -p git -p fs -p project -p git_ui` passes with `--deny warnings`, and the existing suites pass (`cargo test -p project -p git_ui`, 436 tests). Worth a reviewer's attention: trigger `git::StashAll` with focus in the **editor** rather than the Git Panel. That routes through the workspace action registration and is the case the `cx.defer_in` deferral exists to keep from panicking. No new automated tests — the behavior is testable with the existing `git_panel.rs` harness (`init_test`, `GitPanel::new`) if reviewers would prefer coverage over a manual check. ## 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 added - [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 — no new tests; see Testing - [x] Performance impact has been considered and is acceptable — one extra process argument; no new work on any hot path --- Release Notes: - Added an optional stash message prompt when stashing changes ` --------- Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com> |
||
|
|
0500fd9ee9 |
git: Add diff_base setting for showing changes since the default branch (#61501)
# Objective Let git indicators — the editor gutter, file colors, and `git::Diff` — show all changes on the current branch relative to its merge base with the default branch, instead of only uncommitted changes. Supersedes #60398; thanks to @samuelcolvin for the original implementation and motivation. Closes FR-135 ## Solution - New `git.diff_base` setting (`"head"` | `"default_branch"`), applied live and toggleable per session from the editor controls menu ("Diff Against Default Branch"). - Statuses come from a real merge-base-to-worktree tree diff (`git diff --merge-base`), so local edits that revert branch changes correctly show as unchanged. - `GitStore` shares one `DiffBufferList` per repository with the Branch Diff view; `repo_snapshots` and `project_path_git_status` keep returning index/worktree truth, while display surfaces use separate `display_*` APIs. - `BufferDiff` now records what its base is (`DiffBaseKind`); hunks whose base isn't HEAD are read-only in the gutter — stage/restore buttons and keybindings are inert, so committed work can't be silently rewritten. - `git::Diff` follows the setting; new `git::DiffHead` always opens the HEAD diff; `git::BranchDiff` is renamed `git::DiffBranch` (deprecated alias kept). Tradeoffs / known limitations: - Hunk-level staging is unavailable while in `default_branch` mode (whole-file staging via the git panel still works). Staging just the uncommitted sub-ranges of a branch hunk is a follow-up. - Remote hosts running an older server ignore the new `GetTreeDiff.includes_worktree` proto field and degrade to committed-changes-only branch diffs. - Repositories with no resolvable default branch fall back to HEAD-relative behavior; a failed first resolution retries on the next branch-list change. ## Testing - Real-git-repo tests for the merge-base-to-worktree diff's edge cases: files recreated after index deletion, committed deletions recreated on disk, and symlinks. - GPUI tests for status semantics (a branch change reverted on disk shows clean), `git::Diff` routing, live setting changes, and read-only hunk enforcement (restore/stage leave buffer and index untouched). ## 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: - Git: Added a `git.diff_base` setting (`"head"` or `"default_branch"`) that makes the editor gutter, file colors, and diff view show all changes on the current branch since its merge base with the default branch, instead of only uncommitted changes. --------- Co-authored-by: Ben Kunkle <ben@zed.dev> |
||
|
|
134275b0ae |
Avoid unnecessary git scan when the agent creates a checkpoint (#61271)
Agent checkpointing is implemented by staging selected files to a temporary git index file, then creating a commit. To avoid checkpointing commonly-excluded files even when the user doesn't have them in their gitignore, we write a temporary override to .git/info/exclude while running the staging. However, this causes us to do an unnecessary git scan when a checkpoint happens, because in general we want to do this when `.git/info/exclude` changes (the user might have edited it). This PR fixes that by doing the staging in two steps: - First, we stage any tracked files - Then we get a list of untracked files to include and stage those explicitly. The list is obtained by running `git ls-files` with a custom ignore file in addition to the `--standard` ignores; we write that custom ignore file to a path ending in `tmp` under .git, which means that our worktree code will not start a git scan in response to its events (the same way it already works for the temporary index file). .git/info/exclude is never touched. Note that we already listed all untracked files before this PR, in order to exclude the large ones. Release Notes: - Fixed Zed doing unnecessary work when the agent created a checkpoint. |
||
|
|
737f3384f0 |
git_ui: Add option to commit with --no-verify (#61529)
Follow-up to #61185, which moved hook execution from Zed into `git commit` itself. There was previously no way to skip hooks from the UI; #59846 and #56318 attempted to add one on top of the old behavior. This PR adds support on top of the new implementation. Adds a “Skip Hooks” toggle to the commit menus in the Git panel and commit modal, with a corresponding command-palette action. When enabled, the next commit runs with `git commit --no-verify`, skipping pre-commit and commit-msg hooks. The toggle clears after a successful commit or when switching repositories, but remains enabled when a commit fails so it can be retried. Release Notes: - Added a “Skip Hooks” commit option that skips pre-commit and commit-msg hooks. |
||
|
|
2328aebf25 |
git_panel: Show staged and unstaged diff stats (#60815)
# 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 |
||
|
|
5f624dbe96 |
git: Fix operations timing out and commit-msg hook being skipped (#61185)
Closes #44926 Closes #43157 Closes #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. |
||
|
|
6b6393fb0b |
Split out RelPath into a separate crate (#61029)
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 ... |
||
|
|
995cc07249 |
git: Add a gpg wrapper script to route GnuPG prompts via the askpass UI (#58791)
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> |
||
|
|
b220d078bf |
Show tag names in git blame tooltips (#60757)
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> |
||
|
|
6208932d3c |
git: Show submodule changes in commit diffs (#60479)
## 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. |
||
|
|
4e5b6c6b70 |
worktree: Watch .git/refs subdirectories for external ref updates (#60660)
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 ... |
||
|
|
7d3e75a787 |
git_ui: Fix history tab empty and detached HEAD states (#57959)
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> |
||
|
|
601690391b |
git: Load buffer git diff bases with a single batched git process (#59357)
# 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 https://github.com/zed-industries/zed/blob/b2617baa21a83dfcbd8361e285bb2eba84e294ec/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 |
||
|
|
45aabb43a8 |
Show type-changed files in commit diffs (#60422)
# 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 86590085000dca2e9dfe967470fa42423ef7ceac 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. |
||
|
|
e7927edccd |
Support checking out remote HEAD refs (#57648)
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> |
||
|
|
acd55213d1 |
solo_diff_view: Add git action to open file diff and other improvements (#59752)
# 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. |
||
|
|
583fd90c37 |
git_ui: Search commits by hash (#59132)
## 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. |
||
|
|
e0f94ef984 |
git: Detect SCP remotes with non-standard SSH usernames (#59457)
# 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> |
||
|
|
aed5023e80 |
git: Use fast access check for repository in git panel (#59514)
# 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 |
||
|
|
fdebc23ccc |
Prevent archival of manually-created worktrees (#58275)
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. |
||
|
|
cdf9f6ff18 |
git: Avoid unnecessary git repo rescans when unrelated git files change (#59318)
# Objective
Zed triggers many git rescans whenever an outside git command modifies
files inside `.git` dir. This becomes especially problematic when
working on large repos or doing remote development on machines with slow
filesystems.
## Solution
Events for object writes, hook files, lock files, and the reflogs of
HEAD/branches/remote-tracking branches carry no git changes that Zed
cares about beyond what the ref or events already cover. So changes to
these files shouldn't trigger a full git rescan.
## Testing
I extended the existing unittests to add the additionally ignored
directories and lock files.
I also manually verified the changes by viewing the zed git debug logs
that get generated when running `git gc` on a freshly gc'ed repo.
Previously Zed triggered **7 worktree updates**, with these changes it
was reduced to **a single worktree update** which is due to
`.git/packed-refs` which we can't ignore.
**main:**
```
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:52+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:52+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:53+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:53+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
2026-06-13T13:56:54+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:54+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:54+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:54+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:55+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:55+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:55+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:55+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-13T13:56:55+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-13T13:56:56+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-13T13:56:56+01:00 DEBUG [project::git_store] fetched remotes
2026-06-13T13:56:56+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-13T13:56:56+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-13T13:56:56+01:00 DEBUG [project::git_store] load merge details
2026-06-13T13:56:56+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }
```
**This PR:**
```
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] received worktree update for repositories: [UpdatedGitRepository { work_directory_id: ProjectEntryId(0), old_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), new_work_directory_abs_path: Some("/Users/lgeiger/code/zed"), dot_git_abs_path: Some("/Users/lgeiger/code/zed/.git"), repository_dir_abs_path: Some("/Users/lgeiger/code/zed/.git"), common_dir_abs_path: Some("/Users/lgeiger/code/zed/.git") }]
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] local worktree repos changed
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] run scheduled git status scan
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] starting compute snapshot
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] fetched branches, head commit, worktrees
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] fetched remotes
2026-06-15T01:19:51+01:00 DEBUG [git::repository] Checking for git status in [""]
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] fetched statuses, diff stats, stash entries
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] load merge details
2026-06-15T01:19:51+01:00 DEBUG [project::git_store] new merge details: MergeDetails { merge_heads_by_conflicted_path: {}, message: None }```
## 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:
- Reduced number of git operations when repository state changes outside of zed
|
||
|
|
23042e9caa |
git_ui: Add View File action to Git Panel (#59383)
# 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>
|
||
|
|
2bd0a3740d |
git: Reduce amount of git commands when checking for pushed commits (#59069)
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 |
||
|
|
f655e52521 |
git: Reduce number of spawned git processes when retrieving default branch (#59087)
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 |
||
|
|
3f2c5b299c |
git: Reduce number of spawned git processes when retrieving remote URLs (#59053)
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 |
||
|
|
a80e7d2dc6 |
git_ui: Add Add to .git/info/exclude option to context menus (#57044)
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> |
||
|
|
dd00e1800e |
Fix SSH askpass on Windows by invoking cli.exe directly (#52491)
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 |
||
|
|
c4a93ca152 |
Stream git blame parsing (#58733)
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 ... |
||
|
|
da41cecb05 |
git: Fix a regression introduced with removing gitlib2 dep (#58359)
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 |
||
|
|
d3d1f4124c |
Remove git2 (libgit2) dependency (#53453)
## 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> |
||
|
|
51fd135b45 |
git: Further extract gitlib2 dependencies (#58280)
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 |
||
|
|
e36459aead |
ep: Jump example capture (#58236)
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 ... |
||
|
|
f87b2446d8 |
git_graph: Exclude non-standard refs (#54291)
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): https://github.com/microsoft/vscode/blob/341ef7db2e1d95f96c9f63c40a518d25bb455188/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. |
||
|
|
6263155419 |
git: Prefer main over master when detecting default branch (#57398)
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 ... |
||
|
|
9c70888039 |
Update git2 to 0.21.0 and add support for SHA-256 object formatted repos (#57587)
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 |
||
|
|
16ede263e4 |
git: Degrade gracefully when refreshing git state (#57292)
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. |
||
|
|
f7088b3f8a |
git: Recover branch refs when metadata lookup fails (#57285)
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> |
||
|
|
93e7495f8a |
git: Disable log.showSignature for internal commands (#55708)
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> |
||
|
|
4bac6443e8 |
git: Kill git blame process on task drop (#56890)
We replace these tasks often, so we should clean up after ourselves here. Release Notes: - git: Fix git blame processes not getting dropped properly. |
||
|
|
65d40a5724 |
Add a Copy Tag action to the git graph context menu (#56110)
https://github.com/user-attachments/assets/7aa683e3-c52c-49e7-9934-ed4df6a1f8e2 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 `Copy Tag` action to the git graph context menu. |
||
|
|
2ef5304e89 |
git_ui: Add force delete for unmerged branches (#55927)
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. |
||
|
|
643c3cf654 |
Fix git worktree popup popup no worktree when opened in a project (#55053)
## 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> |
||
|
|
914e7ecb65 |
Improve grouping of worktrees by repo in recent projects (#55715)
* 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. |
||
|
|
cfb96a48c0 |
Add git log / history for folders and whole project (#52634)
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> |
||
|
|
17c284803f |
Improve bare repo support (#55153)
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. |
||
|
|
0438bf5268 |
Rust 1.95 (#55104)
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 |
||
|
|
463047c5c7 |
git_panel: Add support for vertically expanding the commit editor (#55043)
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> |