git: Add git worktree picker

[AlvaroParker]

Related discussions #26084

Worktree creations are implemented similar to how branch creations are handled on the branch picker (the user types a new name that's not on the list and a new entry option appears to create a new branch with that name).

2025-09-23.17-12-34.mp4

With this picker you have a few workflows:

• Open the picker and type the name of a branch that's checked out on an existing worktree:
  • Press enter to open the worktree on a new window
  • Press ctrl-enter to open the worktree and replace the current window
• Open the picker and type the name of a new branch or an existing one that's not checked out in another worktree:
  • Press enter to create the worktree and open in a new window. If the branch doesn't exists, we will create a new one based on the branch you have currently checked out. If the branch does exists then we create a worktree with that branch checked out.
  • Press ctrl-enter to do everything on the previous point but instead, replace the current window with the new worktre.
• Open the picker and type the name of a new branch or an existing one that's not checked out in another worktree:
  • If a default branch is detected on the repo, you can create a new worktree based on that branch by pressing ctrl-enter or ctrl-shift-enter. The first one will open a new window and the last one will replace the current one.

Note: If you preffer to not use the system prompt for choosing a directory, you can set "use_system_path_prompts": false in zed settings.

Release Notes:

• Added git worktree picker to open a git worktree on a new window or replace the current one
• Added git worktree creation action

[nwalke]

Any chance of this being a zed extension rather than integrated straight to core? I only ask because I think that would be the faster way to get this and I really want to use it :)

[AlvaroParker]

Hey @nwalke currently zed does not support that kind of extensions. And even if it does, I don't think it would be a good idea to move this to an extension. Zed already has git support so improving that support is the right choice imo.

I don't think it should take too long for a zed team member to review this (and hopefully, aprove it), of course you can always compile this branch from source and use it (at your own risk).

[EpicEric]

Oh nice! I was trying to make an extension myself but I ran into the same issues, and then I stumbled upon this pull request.

My only suggestion is adding git worktree remove functionality as well.

[AlvaroParker]

I'll probably add worktree remove on another PR just because I'm not sure about the UI/UX for that functionality. For now, I think this PR is ready to go.

[cole-miller]

Thanks @AlvaroParker, nice work and sorry for the delay in reviewing--this looks generally good, the only blocker I've noticed is the handling of opening worktrees in remote projects.

[cole-miller]

Thanks! In the latest revision it seems like opening remote worktrees isn't quite working--when I select a worktree from the picker I get a window with the original remote project, not a project for the selected worktree. Based on how open_remote_project_with_existing_connection is used elsewhere, I think we need to construct a remote project to pass into it using Project::remote, instead of using a local project.

[AlvaroParker]

I was hoping in reusing the connection of the active projects when on remote, but when I try creating a new remote Project from the existing connection I hit a few panics on proto_client.rs which indicate we can't have more than 1 project with the same underlying connection. I went for the second best approach, that is, opening a new connection when switching between worktrees.

[cole-miller]

Thanks, nice work on this! Just merging main manually to confirm there aren't any semantic merge conflicts here.

[AlvaroParker]

Awesome! One thing I've notice just now (that I didn't catch), is that when the following happens:

• A branch bar is currently checked out
• A new branch foo is created based off bar
• The user tries to create a new worktree with the name foo based off main

The worktree fails to create because there's already a branch foo based off bar

Should we handle this edge case? Or is the error ok to have? Since the user is trying to create a branch that already exists but based off another branch.

This doesn't happens if the user creates a worktree foo based off bar. If this is the case, the worktree correctly checks out the already created foo branch in the new worktree.

[xtrasmal]

Awesome, thanks @AlvaroParker

[sundaycrafts]

OMG THIS IS AWESOME!!!!! So cool