Closes#39216
Note that this affects all platforms, I'm just using the prefix to make
auto-cherry-picking easier.
Release Notes:
- Fixed shell commands run by agents failing to find installed programs
in some cases.
This fixes a regression in #39557--for the project diff, we rely on
getting an event when a path inside a git repository changes, even if
the git state of the repository didn't change as a result (e.g. a new
modification to a file that already had the "modified" status).
I've also changed this code to send the `UpdateRepository` proto message
even when the git state didn't change, since otherwise we have the same
problem in SSH and collab projects.
Release Notes:
- N/A
When running flycheck, I've noticed that scrolling starts to lag:
https://github.com/user-attachments/assets/b0bef0a3-ccbd-479d-a385-273398086d38
When checking the trace, it is notable that project panel updates its
entire tree multiple times during flycheck:
<img width="2032" height="1136" alt="image"
src="https://github.com/user-attachments/assets/d1935e77-3b00-4be5-a12a-8a17a9d64202"
/>
[scrolling.trace.zip](https://github.com/user-attachments/files/22710852/scrolling.trace.zip)
Turns out, `target/debug` directory is loaded by Zed (presumably,
reported by langserver as there are sources generated by bindgen and
proto that need to be loaded), and `target/debug/build` directory
received multiple events of a `None` kind for Zed, which trigger the
rescans.
Rework the logic to omit the `None`-kind events in Zed, and to avoid
excessive repo updates if not needed.
Release Notes:
- Improved worktree FS event emits in gitignored directories
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Closes#38571
Release Notes:
- git: Fixed git features not working when git was installed in an
unusual location.
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
### Summary
* Auto-activates the active repository when opening a buffer.
* Prepares branching for future support of a user choice (e.g.,
`auto_activate_repo_on_open` flag).
### Release Notes
* **Improved**: Opening a buffer now automatically updates the active
repository.
std commands can block for an arbitrary duration and so runs risk of
blocking tasks for too long. This replaces all such uses where sensible
with async processes.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes https://github.com/zed-industries/zed/issues/38690Closes#37353
### Background
On Windows, paths are normally separated by `\`, unlike mac and linux
where they are separated by `/`. When editing code in a project that
uses a different path style than your local system (e.g. remoting from
Windows to Linux, using WSL, and collaboration between windows and unix
users), the correct separator for a path may differ from the "native"
separator.
Previously, to work around this, Zed converted paths' separators in
numerous places. This was applied to both absolute and relative paths,
leading to incorrect conversions in some cases.
### Solution
Many code paths in Zed use paths that are *relative* to either a
worktree root or a git repository. This PR introduces a dedicated type
for these paths called `RelPath`, which stores the path in the same way
regardless of host platform, and offers `Path`-like manipulation APIs.
RelPath supports *displaying* the path using either separator, so that
we can display paths in a style that is determined at runtime based on
the current project.
The representation of absolute paths is left untouched, for now.
Absolute paths are different from relative paths because (except in
contexts where we know that the path refers to the local filesystem)
they should generally be treated as opaque strings. Currently we use a
mix of types for these paths (std::path::Path, String, SanitizedPath).
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Peter Tripp <petertripp@gmail.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Closes #ISSUE
This PR continues work from #32821 by adding a stash entry picker for
pop/drop operations. Additionally, the stash pop action in the git panel
is now disabled when no stash entries exist, preventing error logs from
attempted pops on empty stashes.
Preview:
<img width="1920" height="1256" alt="Screenshot From 2025-09-11
14-08-31"
src="https://github.com/user-attachments/assets/b2f32974-8c69-4e50-8951-24ab2cf93c12"
/>
<img width="1920" height="1256" alt="Screenshot From 2025-09-11
14-08-12"
src="https://github.com/user-attachments/assets/992ce237-43c9-456e-979c-c2e2149d633e"
/>
Release Notes:
- Added a stash picker to pop and drop a specific stash entry
- Disabled the stash pop action on the git panel when no stash entries
exist
- Added git stash apply command
- Added git stash drop command
This is a pure refactor that consolidates all SSH remoting logic such
that it should be straightforward to add another transport to the
remoting system.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
This removes around 900 unnecessary clones, ranging from cloning a few
ints all the way to large data structures and images.
A lot of these were fixed using `cargo clippy --fix --workspace
--all-targets`, however it often breaks other lints and needs to be run
again. This was then followed up with some manual fixing.
I understand this is a large diff, but all the changes are pretty
trivial. Rust is doing some heavy lifting here for us. Once I get it up
to speed with main, I'd appreciate this getting merged rather sooner
than later.
Release Notes:
- N/A
Closes #ISSUE
Adds `merge_message` field to the `UpdateRepository` proto message so
that suggested merge messages are displayed in remote projects.
Release Notes:
- git: Fixed an issue where suggested merge commit messages would not
appear for remote projects
This PR adds preliminary git clone support through using the new
`GitClone` action. This works with SSH connections too.
- [x] Get backend working
- [x] Add a UI to interact with this
Future follow-ups:
- Polish the UI
- Have the path select prompt say "Select Repository clone target"
instead of “Open”
- Use Zed path prompt if the user has that as a setting
- Add support for cloning from a user's GitHub repositories directly
Release Notes:
- Add the ability to clone remote git repositories through the `git:
Clone` action
---------
Co-authored-by: hpmcdona <hayden_mcdonald@brown.edu>
Release Notes:
- Edit Prediction: Added Git info to edit predictions requests (only
sent for opensource projects when data collection is enabled). The sent
Git info is the SHA of the current commit and the URLs for the `origin`
and `upstream` remotes.
Closes#33700
The option shows up as an icon that appears on entries that would create
a new branch. You can also branch from the default by secondary
confirming, which the icon has a tooltip for as well.
We based the default branch on the results from this command: `git
symbolic-ref refs/remotes/upstream/HEAD` and fallback to `git
symbolic-ref refs/remotes/origin/HEAD`
Release Notes:
- Add option to create a branch from a default branch in git branch
picker
---------
Co-authored-by: Cole Miller <cole@zed.dev>
In this PR we've reworked how git status updates are processed. Most
notable change is moving the processing into a background thread (and
splitting it across multiple background workers). We believe it is safe
to do so, as worktree events are not deterministic (fs updates are not
guaranteed to come in any order etc), so I've figured that git store
should not be overly order-reliant anyways.
Note that this PR does not solve perf issues wholesale - other parts of
the system are still slow to process stuff (which I plan to nuke soon).
Related to #34302
Release Notes:
- Improved Zed's performance in projects with large # of repositories
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
This gets rid of the need to pass context to all cursor functions. In
practice context is always immutable when interacting with cursors.
A nicety of this is in the follow-up PR we will be able to implement
Iterator for all Cursors/filter cursors (hell, we may be able to get rid
of filter cursor altogether, as it is just a custom `filter` impl on
iterator trait).
Release Notes:
- N/A
I don't want to fetch `--all` branch, we should can picker which remote
to fetch.
Release Notes:
- Added the `git::FetchFrom` action to fetch from a single remote.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Previously, we only enabled merge conflict parsing for files that were
unmerged at the last time a change was detected to the repo's merge
heads. Now we enable the parsing for these files *and* any files that
are currently unmerged.
The old strategy meant that conflicts produced via `git stash pop` would
not be parsed.
Release Notes:
- Fixed parsing of merge conflicts when the conflict was produced by a
`git stash pop`
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
Release Notes:
- Changed the git branch picker to make remote-tracking branches less
prominent
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
This PR updates the git store to not register a change in a repository's
merge heads until conflicted paths are seen.
We currently use the repository's merge heads only to decide when the
list of conflicted paths should be refreshed. Previously, the logic
looked like this:
- Whenever we see a change in the merge heads, set the list of
conflicted paths by filtering the output of `git status`.
It turns out that when a conflicting merge takes a while, we can see
this sequence of events:
1. We get an event in .git and reload statuses and merge heads.
Previously there were no merge heads, and now we have some, but git
hasn't finished figuring out which paths have conflicts, so we set the
list of conflicted paths to `[]`.
2. Git finishes computing the list of conflicted paths, and we run
another scan that picks these up from `git status`, but then we throw
them away because the merge heads are the same as in (1).
By not updating our stored merge heads until we see some conflicts in
`git status`, we delay this step until (2), and so the conflicted paths
show up in the git panel as intended.
This means that our merge heads state no longer matches what's on disk
(in particular, during a clean merge we'll never update them at all),
but that's okay because we only keep this state for the purpose of
organizing conflicts.
Release Notes:
- Fixed a bug that could cause conflicted paths to not appear in their
own section in the git panel.
Since #28065 merged we've seen deadlocks inside iconv when opening Zed
in a repository containing many submodules. These calls to iconv happen
inside libgit2, in our implementations of the methods `head_sha`,
`merge_head_shas`, and `show` on `RealGitRepository`. This PR moves
those methods to use the git CLI instead, sidestepping the issue. For
the sake of efficiency, a new `revparse_batch` method is added that uses
`git cat-file` to resolve several ref names in one invocation. I
originally intended to make `show` operate in batch mode as well (or
instead), but I can't see a good way to do that with the git CLI; `git
show` always bails on the first ref that it can't resolve, and
`for-each-ref` doesn't support symbolic refs like `HEAD`.
Separately, I removed the calls to `show` in `MergeDetails::load`, going
back to only loading the SHAs of the various merge heads. Loading full
commit details was intended to support the inlays feature that ended up
being cut from #28065, and we can add it back in when we need it.
Release Notes:
- N/A
Cole Miller
Andrew FarkasandCole Miller
Piotr Osiewicz
Kirill BulatovandCole Miller
Lukas Wirth
rufevean
Max BrunsfeldandCole Miller
Alvaro Parker
Lev ZakharovandConrad Irwin
Michael Sloan
tidely
Ben Kunkle
Anthony Eidandhpmcdona
Eric Cornelissen
feeiyuandCole Miller
CharlesChen0823andCole Miller
Joseph T. Lyons
Tymoteusz Makowski