jesseduffield
Worktree view
Is your feature request related to a problem? Please describe. Currently, I do the following to remove stale worktrees:
% cd dir_that_contains_bare
% git worktree remove ./old_worktree
fatal: 'bck_dev_dbi_rename' contains modified or untracked files, use --force to delete it
% cd ./old_worktree
% git status
## status output and action taken (or inaction)
% cd -
% git worktree remove -f ./old_worktree
% git branch -d ./old_worktree_branch
Usually, I find myself doing this two or three times, because I often wait until things become untidy and I have a lot of merged worktrees just lying around.
Describe the solution you'd like In the same way that lazygit presents the user with a list of modified files and lets the user act on them and the branches that exist in the repo, I'd like to see the user presented with a similar worktree view.
This view would be automatically presented to the user. Upon invocation, lazygit would look for a bare repo clone and a .git file that sets gitdir to that bare clone. If those two conditions are true, the worktree view would be presented.
From that view, I could do everything that I describe in the workflow above, and more! One potential example: the user could easily create worktrees from existing branches on various remotes.
Describe alternatives you've considered I could script all of the above in a shell script, adding logic that asked for confirmation before it forced removal of the worktree.
Additional context #1280
I'm not fully across how worktrees work but from what little I've seen they seem like they'd be a great addition to lazygit.
It would be awesome to have lazygit detect that it is in a bare repo and show a different view focused on worktrees. The ability to list existing worktrees and create new ones from existing branches would be fantastic.
For this to really fit in with developer workflows, I think you would need hooks that can be run before/after each action such as for copying common configuration into each worktree after it is created, or launching a new ide/terminal for use with that workfree.
I currently use scripts for:
- Listing existing worktrees
- Opening an existing worktree directory in vscode
- Adding a worktree for an existing remote branch
- Creating a new branch from a remote branch and adding it as a worktree
- Remove a worktree (In each of these, config is generated/copied into the worktree directory as well)
I can happily share the script/workflow if this will be developed into a feature.
worktrees and bare repos are two different issues. I use worktrees but with a standard clone of a repo. I don't see what value a developer gets from a bare clone.
worktrees and bare repos are two different issues. I use worktrees but with a standard clone of a repo. I don't see what value a developer gets from a bare clone.
What value do you get from a standard clone if you use worktrees? All added worktrees are shown as changes in the local repo which doesn't make sense to me.
What value do you get from a standard clone if you use worktrees?
I've often used it to quickly spin up our master codebase without having to create/teardown a worktree.
All added worktrees are shown as changes in the local repo which doesn't make sense to me.
They're not for me, are you sure about that?
They're not for me, are you sure about that?
Steps I do:
git clone <git-repo>cd <git-repo-name>git worktree add developgit status
On branch master
Your branch is up to date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
develop/
nothing added to commit but untracked files present (use "git add" to track)
Ah, right, I don't do that.
My steps:
git clone <git-repo>cd <git-repo-name>git worktree add ../develop
Our company monorepo is the only place I use worktrees and I've checked it out into a directory called ~/dev/m/mono so my worktree directories are sort of like ~/dev/m/JIRA_ID-short-description next to the monorepo directory.
You can also add custom command to force delete worktree since worktree with submodule cannot be deleted by pressing 'd' in worktree context. I added 'D' to force delete a worktree.
customCommands:
- key: 'D'
context: 'worktrees'
command: 'git worktree remove -f {{.SelectedWorktree.Path | quote}}'
prompts:
- type: 'confirm'
title: 'Force remove worktree'
body: 'Are you sure you want force remove "{{.SelectedWorktree.Path}}"?'
@socketbox now that we have a worktrees view, can we close this off?
the worktree view is fantastic but it doesn't work in bare repos as you cannot start lazygit in bare repo. you need to first enter worktree and then you are able to change freely between them. This is not acceptable to anyone that uses bare repos and in-repo worktrees.
Could we instead of force-exiting the lazygit in case of bare repo, display a dialog with worktree list for the user to select? And exit only if user cancels or there are no worktrees know in the repo?
