The feature request
Worktrees are currently bit clunky to work with in GitHub Desktop Plus, at least for me.
One major pain point is, that I cannot create a new worktree from an existing branch.
The workaround is, to create a worktree with a different name than the branch (since you cannot create a new worktree with the same name as an existing branch), then checkout the existing branch, rename either the worktree or the branch (if necessary bring the changes to the other branch) and delete the unused branch.
This is very clunky.
Proposed solution
There are two solutions that come to my mind. I prefer the first solution, but I like both and I would actually propose to implement both:
Solution 1 - Create a worktree from an existing branch
- Have an existing branch
- Create new worktree with this new option (like with a right click on the branch)
- Worktree with same name as branch will be created and with the existing branch checked out
Solution 2 - Bring changes to new worktree (similar, but not identical to the switch branch flow)
- Have uncommited changes
- Create new worktree
- Get being asked if you want to bring the uncommited changes to the newly created branch (like if you switch branches, where you also get asked if you want to bring your changes with you)
The question if you want to bring your changes with you into the newly created branch created by the newly created worktree, will only be ask once on creation.
Additional context
No response
The feature request
Worktrees are currently bit clunky to work with in GitHub Desktop Plus, at least for me.
One major pain point is, that I cannot create a new worktree from an existing branch.
The workaround is, to create a worktree with a different name than the branch (since you cannot create a new worktree with the same name as an existing branch), then checkout the existing branch, rename either the worktree or the branch (if necessary bring the changes to the other branch) and delete the unused branch.
This is very clunky.
Proposed solution
There are two solutions that come to my mind. I prefer the first solution, but I like both and I would actually propose to implement both:
Solution 1 - Create a worktree from an existing branch
Solution 2 - Bring changes to new worktree (similar, but not identical to the switch branch flow)
The question if you want to bring your changes with you into the newly created branch created by the newly created worktree, will only be ask once on creation.
Additional context
No response