## Context
This uses `git log` to get a basic search working in the git graph. This
is one of the last blockers until a full release, the others being
improvements to the graph canvas UI.
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
When a git worktree is in a detached HEAD state (e.g. after `git
checkout --detach`), the workspace for that worktree would disappear
from the sidebar UI, and if the workspace was currently open your UI
would just disappear.
This happened because `parse_worktrees_from_str` silently dropped any
worktree entries without a `branch` line in the porcelain output, which
cascaded through the `linked_worktrees` list and caused
`prune_stale_worktree_workspaces` to remove the workspace.
This PR:
- Makes `Worktree::ref_name` an `Option<SharedString>` so detached
worktrees can be represented
- Renames `Worktree::branch()` to `Worktree::display_name()`, which
returns the branch name when available or the short SHA as a fallback
(mirroring how the title bar already handles detached HEAD for
repositories)
- Updates `parse_worktrees_from_str` to include detached and bare
worktree entries instead of dropping them
- Filters detached worktrees out of the worktree picker UI, preserving
the existing product decision to only show branch-based worktrees there
## Self-Review Checklist
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
## Summary
Zed's git checkpoint code was assuming that repository-local metadata
always lives under `<working-directory>/.git/...`.
That assumption breaks for repositories where `.git` is a file instead
of a directory, most notably:
- git submodules
- git worktrees
In those layouts, `.git` contains a `gitdir: ...` pointer to the real
git directory. When checkpoint creation or restore tries to build paths
like `.git/index-<uuid>.tmp` or `.git/info/exclude`, those path
operations fail with `Not a directory (os error 20)`.
In practice, that shows up as checkpoint failures in ACP threads for
worktrees and submodules.
## Root Cause
`GitBinary` tracked the repository working directory, but it did not
track the resolved git directory.
As a result, checkpoint-related helpers derived temporary index and
exclude paths from the working tree:
- temp index path creation
- copying the default index into the temp index
- exclude override handling
That works for a plain repository where `.git` is a directory, but not
when `.git` is a pointer file.
## Changes
- Thread the resolved git directory from `RealGitRepository::path()`
into `GitBinary`.
- Add a dedicated `git_directory` field to `GitBinary`.
- Use `git_directory` instead of `<working-directory>/.git` for:
- temp index file paths
- copying the default `index`
- `info/exclude` override paths
- Keep the working directory unchanged for command execution; only
metadata path resolution changes.
- Add a regression test that verifies temp index files are created under
the real gitdir, not under `<working-directory>/.git`.
## Why this approach
The minimal correct fix is to distinguish between:
- the working directory used to run git commands, and
- the actual git directory used to store repository metadata
Git itself already makes that distinction, and
`git2::Repository::path()` gives us the resolved gitdir directly.
Reusing that value keeps the fix small and avoids special-casing
submodules or worktrees elsewhere.
## User-visible impact
Before this change, checkpoint operations could fail in repositories
where `.git` is not a directory, producing errors like:
Not a directory (os error 20)
After this change, checkpoint-related git metadata is read and written
from the real gitdir, so ACP checkpoints work in submodules and
worktrees the same way they do in regular repositories.
## Testing
- `cargo fmt -p git`
- `cargo test -p git --lib`
- `cargo clippy -p git --lib --tests -- -D warnings`
Added regression coverage:
- `test_path_for_index_id_uses_real_git_directory`
If you want, I can also compress this into a more GitHub-PR-native
version with sections like `## Problem`, `## Fix`, and `## Validation`.
Release Notes
- Fixed `.git` handling when `.git` is a file instead of directory, e.g.
when using worktrees or submodules.
* [x] Display original project name as root folder in project panel,
titlebar
* [x] When manually creating worktrees, ensure final path component is
original project name
* [x] Display original project name, worktree name, and branch name in
titlebar
* [x] Only show main checkout in project switcher
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Closes#48256
It appears that the current git remotes support was implemented in
#42819, following the design described in
https://github.com/zed-industries/zed/pull/42486#issuecomment-3524092306.
That design does not include an interaction for deleting remotes, but
the delete remote branch action was mistakenly implemented as deleting
the remote itself.
After this PR, there should be no code paths that use `remove_remote`
anymore. I've kept it for now though, as it may be useful when we
introduce the corresponding interaction in the future.
Release Notes:
- Fixed a bug where deleting a remote branch from the branch picker
would incorrectly remove the entire remote configuration
When on a untrusted project, if one was to try and use the commit
generation functionality, the command would fail because of the `-c
diff.external` configuration provided in `GitBinary::build_command`, as
git would interpret this as `""` and try to run that command.
This `-c diff.external` is a good safeguard to have on untrusted
repositories because it prevents random commands, configured in
`.git/config` from being run. For example, if one uses `git config
diff.external "touch bananas.txt"` and then run `git diff`, a new
`bananas.txt` file would be created.
However, it was still possible to bypass this safeguard using the
following strategy:
1. Specify a custom diff for a specific file format. For example, for
markdown files, with `printf '*.md diff=pwned\n' > .gitattributes`
2. Update the command run by the `pwned` diff, for example, `git config
diff.pwned.command "touch bananas.txt"`
3. Open Zed and attempt to generate a commit message in an untrusted
repository and check that a new `bananas.txt` file was created
This is only prevented by using the `--no-ext-diff` flag on the `diff`
command, so a new `GitBinary::build_diff_command` has been introduced
which simply wraps `GitBinary::build_command` and adds the
`--no-ext-diff` flag, if necessary.
As a side-effect, this also makes it so that generating a commit message
in an untrusted repository works again, which was accidentally broken on
https://github.com/zed-industries/zed/pull/50649 .
Before you mark this PR as ready for review, make sure that you have:
- [X] Added a solid test coverage and/or screenshots from doing manual
testing
- [X] Done a self-review taking into account security and performance
aspects
- [X] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Fixed commit message generation in untrusted repositories
This will help with test times (in some cases), as nextest cannot figure
out whether a given rdep is actually an alive edge of the build graph
Closes #ISSUE
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
Add a `git::RestoreAndNext` action that restores the diff hunk at the
cursor and advances to the next hunk. In the git diff view, the default
restore keybinding (`cmd-alt-z` on macOS, `ctrl-k ctrl-r` on
Linux/Windows) is remapped to this action so users can quickly restore
hunks in sequence. Also refactor `go_to_hunk_before_or_after_position`
to accept a `wrap_around` parameter, eliminating duplicated
hunk-navigation logic in `do_stage_or_unstage_and_next` and
`restore_and_next`.
Release Notes:
- Added a `git: restore and next` action that restores the diff hunk at
the cursor and moves to the next one. In the git diff view, the
default restore keybinding (`cmd-alt-z` on macOS, `ctrl-k ctrl-r` on
Linux/Windows) now triggers this action instead of `git: restore`.
---------
Co-authored-by: Afonso <4775087+afonsograca@users.noreply.github.com>
follow up on: https://github.com/zed-industries/zed/pull/50649
When committing in a restrictive workspace we avoid running git hooks
instead of failing the commit because hooks aren't allowed. I also
passed in more git cli hardening configurations to use when Zed spawns
git commands
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
Follow up on: https://github.com/zed-industries/zed/pull/49519
This PR reworks how Zed calculates diff num stats by moving the
calculation to the `RepositorySnapshot` layer, instead of the
`GitPanel`. This has a couple of benefits:
1. Snapshot recalculations are already set up to recompute on file
system changes and only update the affected files. This means that diff
stats don't need to manage their own subscription or states anymore like
they did in the original PR.
2. We're able to further separate the data layer from the UI. Before,
the git panel owned all the subscriptions and tasks that refreshed the
diff stat, now the repository does, which is more inline with the code
base.
3. Integration tests are cleaner because `FakeRepository` can handle all
the data and calculations of diff stat and make it accessible to more
tests in the codebase. Because a lot of tests wouldn't initialize the
git panel when they used the git repository.
4. This made implementing remote/collab support for this feature
streamline. Remote clients wouldn't get the same buffer events as local
clients, so they wouldn't know that the diff stat state has been updated
and invalidate their data.
5. File system changes that happened outside of Zed now trigger the diff
stat refresh because we're using the `RepositorySnapshot`.
I added some integration tests as well to make sure collab support is
working this time. Finally, adding the initial diff calculation to
`compute_snapshot` didn't affect performance for me when checking
against chromium's diff with HEAD~1000. So this should be a safe change
to make.
I decided to add diff stats on the status entry struct because it made
updating changed paths and the collab database much simpler than having
two separate SumTrees. Also whenever the UI got a file's status it would
check its diff stat as well, so this change makes that code more
streamlined as well.
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing.
- [x] Done a self-review taking into account security and performance
aspects.
Release Notes:
- N/A
This PR cleans up the git command spawning by wrapping everything in
GitBinary instead to follow a builder/factory pattern. It also extends
trusted workspace support to git commands.
I also added a `clippy.toml` configuration to our git crate that warns
against using `Command` struct to spawn git commands instead of going
through `GitBinary`. This should help us maintain the factory pattern in
the future
Before you mark this PR as ready for review, make sure that you have:
- [x] Added solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
Release Notes:
- git: Add trusted workspace support for Zed's git integration
The main issue is that we weren't forwarding the proto messages through
the collab server to the host. After fixing that I added integration
tests to cover local worktrees, remote worktrees, and ssh worktrees.
I also fixed a bug with FakeRepository where it wouldn't name its
current branch as a worktree when calling git worktree, which doesn't
match the behavior of the git binary.
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
Release Notes:
- git: Fix bug that caused the git worktree picker from displaying and
creating worktrees over collab
We were trying to mitigate these by passing `.` instead of ``, but it
turns out that git2 also panics internally for that. It also just
doesn't make sense to look up the index text (or committed text) for an
empty path, because a file should always have a nonempty repo path.
Closes ZED-560
Release Notes:
- N/A
This PR adds the small UI change of `git diff --numstat` to the git
panel so you can see the number of additions/deletions per file. There
is an option in the settings UI for this under `git_panel`.`diff_stats`.
This option is set to `false` by default.
<!-- initial version <img width="1648" height="977" alt="Screenshot
2026-02-18 at 18 42 47"
src="https://github.com/user-attachments/assets/b8b7f07c-9c73-4d06-9734-8f1cf30ce296"
/> -->
<img width="1648" height="977" alt="Screenshot 2026-02-18 at 21 25 02"
src="https://github.com/user-attachments/assets/73257854-6168-4d12-84f8-27c9e0abe89f"
/>
Release Notes:
- Added git diff stats to git panel entries
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Anthony Eid <anthony@zed.dev>
## Summary
Fixes **ZED-2XA** — "Unexpected duplicated status entries: Untracked and
Untracked" crash.
**Impact:** 22 occurrences, 3 users affected (Sentry). The panic was
introduced in #23483 (2025-01-22) which added the `dedup_by` logic for
handling deleted-in-index + untracked file combinations.
No related GitHub issues were found filed against this crash.
## Root Cause
`GitStatus::from_str` sorts entries by path and then calls `dedup_by` to
merge duplicate entries. The only handled case was `(INDEX_DELETED,
Untracked)` — all other duplicates hit a catch-all `panic!`. In
practice, git can produce duplicate `??` (untracked) entries for the
same path, which triggered this crash.
## Fix
- Identical duplicate statuses (e.g., `Untracked, Untracked`) are now
silently deduplicated (keep one)
- Other unexpected duplicate combinations log a warning instead of
crashing
- Added a regression test that parses `"?? file.txt\0?? file.txt"` and
verifies it produces a single entry
## Verification
- Reproduction test passes: `cargo test -p git --
test_duplicate_untracked_entries`
- Full crate tests pass: `cargo test -p git` (20/20)
- Clippy clean: `./script/clippy`
Release Notes:
- Fixed a crash when git produces duplicate status entries for the same
file path
Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
The AI-assisted "Review Diff" action was only working for committed
changes because we were passing HEAD in the git command. Without it, it
captures all of the working tree changes, the same way the Branch Diff
view itself does. I think this is now better and more intuitive, because
it shouldn't be required that you commit the changes to have them
quickly reviewed by an agent.
Release Notes:
- N/A
- Use git panel icons to show a changed file's state
- Centered avatar at top and move close button to top right
- Made changed file list scrollable
- clicking on a file open's it's historic commit view
- Note: The commit view doesn't fully populate the multibuffer, will fix
this in a different PR because it involves updating the commit view
interface to add more functionality
## Before
<img width="602" height="1704" alt="image"
src="https://github.com/user-attachments/assets/75a12fff-8a6a-4d0f-90dd-544adb0c2814"
/>
## After
<img width="227" height="856" alt="Screenshot 2026-02-23 at 1 23 45 PM"
src="https://github.com/user-attachments/assets/244cc9f3-e94d-4cc6-ac46-80fe70a619ff"
/>
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
Add `agent_worktree_directory` to `GitSettings` for configuring where
agent worktrees are stored (default: Zed data dir). Remove `Copy` derive
from `GitSettings`/`GitContentSettings` (incompatible with String field)
and fix downstream `.as_ref().unwrap()` call sites.
Define `AgentGitWorktreeInfo` (branch, worktree_path, base_ref) and add
it to `DbThread` + `DbThreadMetadata` for persistence and session list
display.
Closes AI-33
Release Notes:
- N/A
This PR adds a button in the `git: branch diff` view that allows to
quickly and easily send the entire diff to your last used agent for a
review. What this does is automatically submits a (pre-written and
generic) prompt to the last agents you were using in the agent panel
with the whole content of your diff.
<img width="750" height="1964" alt="Screenshot 2026-02-18 at 3 35@2x"
src="https://github.com/user-attachments/assets/493d8cf4-4815-4b01-91a0-6a39ad6219fe"
/>
Release Notes:
- Added a "Review Branch" button in the `git: branch diff` view so that
the whole diff can be quickly sent for review to an agent.
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Add `remove_worktree()` and `rename_worktree()` to the `GitRepository`
trait with `RealGitRepository` implementations that shell out to `git
worktree remove/move`.
Implement all 4 worktree methods (`worktrees`, `create_worktree`,
`remove_worktree`, `rename_worktree`) on `FakeGitRepository` backed by
`FakeGitRepositoryState`, with `simulated_create_worktree_error` for
test-time fault injection.
Add `set_create_worktree_error()` helper on `FakeFs`.
Add `parse_worktrees_from_str` helper and 7 new tests covering real git
operations and fake worktree lifecycle.
Closes AI-31
Release Notes:
- N/A
Here's some backstory:
* on macOS, @cole-miller and I noticed that since roughly Oct 2025, due
to some changes to latest macOS Tahoe, for any spawned child process we
needed to reset Mach exception ports
(https://github.com/zed-industries/zed/issues/36754 +
6e8f2d2ebe)
* the changes in that PR achieve that via `pre_exec` hook on
`std::process::Command` which then abandons `posix_spawn` syscall for
`fork` + `execve` dance on macOS (we tracked it down in Rust's std
implementation)
* as it turns out, `fork` + `execve` is pretty expensive on macOS
(apparently way more so than on other OSes like Linux) and `fork` takes
a process-wide lock on the allocator which is bad
* however, since we wanna reset exception ports on the child, the only
official way supported by Rust's std is to use `pre_exec` hook
* posix_spawn on macOS exposes this tho via a macOS specific extension
to that syscall `posix_spawnattr_setexceptionports_np` but there is no
way to use that via any standard interfaces in `std::process::Command`
* thus, it seemed like a good idea to instead create our own custom
Command wrapper that on non-macOS hosts is a zero-cost wrapper of
`smol::process::Command`, while on macOS we reimplement the minimum to
achieve `smol::process::Command` with `posix_spawn` under-the-hood
Notably, this changeset improves git-blame in very large repos
significantly.
Release Notes:
- Fixed performance spawning child processes on macOS by always forcing
`posix_spawn` no matter what.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
This reverts commit 839b4f1e60.
This changed caused a regression on Windows (reproducer: have a repo
with some unstaged changes to tracked files, and click `Commit
Tracked`).
cc @marcocondrache
Release Notes:
- N/A (nightly only)
Git commands can fail when staging or unstaging a very large number of
files because each file path is passed as a separate CLI argument. Once
the argument list grows beyond the OS limit, git errors with Argument
list too long (os error 7).
Since git 2.26, pathspecs can be read from stdin, which lets us avoid
passing thousands of paths as arguments and bypass this limitation.
I looked for existing issues related to this but couldn’t find any.
Repro:
- Clone rust-lang repo
- Delete root tests folder
- Try to stage or unstage (40,000+ files)
- Git fails with Argument list too long (os error 7)
Release Notes:
- Fixed an issue where stage/unstage could fail when operating on a very
large number of files
GitHub's commit API endpoint is rate limited to 60 requests/hour for
unauthenticated users. This causes avatar loading to fail after toggling
blame a few times.
This PR uses GitHub's CDN avatar endpoint
`https://avatars.githubusercontent.com/u/e?email={email}&s=128` instead,
which doesn't count against API rate limits. The author email is already
available from local git data (blame output), so
no API calls are needed.
- When author email is available, constructs the CDN URL directly (zero
API calls)
- Falls back to existing API-based behavior when email is unavailable
- Adds unit tests for URL construction
Closes#47590
## Test plan
- [x] `./script/clippy` passes
- [x] `cargo test -p git_hosting_providers` passes (89 tests including 3
new ones i added)
- [ ] Manual test: Open a file, toggle git blame, verify avatars load
without hitting rate limits
Release Notes:
- Fixed GitHub avatar rate limiting in git blame by using CDN endpoint
instead of API calls (#47590)
Basically just replaced `SharedString::new("` with
`SharedShring::new_static("` which removes the allocation to `Arc<str>`.
Unfortunately this can't be enforced at compile time without trait
specialization which is only available on nightly. You could assert that
`TypeId`'s differ, but `TypeId` only exists at runtime.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#26866
### Summary
Adds a git graph to Zed, accessible via the `git_graph::Open` action if
a project has an active repository. There's still more to do, but this
is a solid foundation to expand upon. The code structure is in line with
Zed's codebase and shouldn't require architectural changes to add
missing features.
The git graph can be opened via the command palette (`git graph: open`)
or by binding a key to `git_graph::Open`. It's available when the
project has an active git repository.
### Architecture
Similar to the Debugger, the git graph is split between a data layer and
a view/UI layer. When the view layer is rendering, it queries the data
layer for its active state. This setup allows the data layer to lazily
request graph data (only when needed for rendering), abstracts collab
from the view layer, allows most of the data loading to happen on a
background thread, and makes caching easy to implement.
#### Graph Loading
The graph data is loaded in two phases:
1. `Repository::graph_data()` streams commit structure (SHA, parents,
refs) in chunks of 1000 via `git log`
2. `CommitDataReader` lazily fetches full commit details (author,
timestamp, subject) on-demand using a persistent `git cat-file --batch`
process
This two-phase approach makes the initial loading of the graph as fast
as possible, because `git log` takes significantly longer when all the
needed graph data is queried through it. Zed then lazily loads commits
in the user's viewport through `cat-file --batch`. This makes scrolling
to any place in the graph extremely snappy and benefits the
collaborative architecture by only fetching data needed to render the
graph. It also allows Zed to share commit data between different graph
visualizations (e.g., date order vs. topological order).
#### Performance
Tested on both the Zed and LLVM repositories with good performance in
both cases. The two-phase loading approach and lazy fetching keep the UI
responsive even with large commit histories.
#### Testing
I added property testing that builds randomized commit graphs and
verifies that the graph is constructed correctly. This also works as an
integration test and will be expanded in the future to test collab graph
visualization, graph filtering, commit actions, etc.
### New Crate
- `git_graph` (GPL-licensed) — contains UI and graph computation logic
### Not Yet Implemented
- Remote repository support (collab)
- Filtering by branch
- Commit actions (checkout, cherry-pick, etc.)
- Search
- Open commit view for selected commit
- Resizable columns
- Column filtering
#### Reference
<img width="1624" height="976" alt="Screenshot 2025-01-22 at 8 15 39 PM"
src="https://github.com/user-attachments/assets/0f10924a-3964-462f-b320-42d84d02f7bf"
/>
Special thanks to [Alberto Slavica](https://github.com/pyundev) for
submitting #44405, which was a good base to work off of.
Release Notes:
- git: Add initial version of git graph
---------
Co-authored-by: pyundev <pyundev@users.noreply.github.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
This happens when a user's default branch has different remote and local
versions on their system. Because we would get a diff using just a
branch name without including it's remote name as well
This is a better default because it's far less confusing from a user's
perspective to debug what's going on.
Release Notes:
- git: Fix BranchDiff showing incorrect diffs when default local branch
is out of sync with the remote default branch
Also improves the commit view to use the same status-based buffer header
visual overrides as the project diff as a driveby.
Fixes https://github.com/zed-industries/zed/issues/45735
Release Notes:
- git: Binary files are no longer shown in garbled form when viewing an
old commit.
Closes#42217
Release Notes:
- Added/Fixed/Improved ...
added "Create Pull Request" Command when searching on the command
Palette
For more details, please refer to the issue, thank you.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Closes#26424
Supersedes #35328
Originally, `git::blame` uses its own `ParsedCommitMessage` as the
source for the commit information, including the PR section. This
changes unifies this with `git::repository` and `git_ui::git_panel` by
moving this and some other commit-related structs to `git::commit`
instead, and making both `git_ui::blame_ui` and `git_ui::git_panel` pull
their information from these structs.
Release notes :
- (Let's Git Together) Fixed the commit tooltip in the git panel not
showing information like avatars.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Fix git hook hang when using with `prek`. Can see
[comments](https://github.com/zed-industries/zed/issues/44057#issuecomment-3606837089),
this is easy test, should using release build, debug build sometimes not
hang.
The issue existing long time, see issue #37293 , and then in commit
#42239 this issue had fixed. but in commit #43285 broken again. So I
reference the implementation in #42239, then this code work.
I MUST CLAIM, I really don't known what happend, and why this code work.
But it worked.
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
We already store the remote URLs for `origin` and `upstream` in the
`RepositorySnapshot`, so just use that data. Follow-up to #44092.
Release Notes:
- N/A
