Feature Request: git worktrees

[airtonix]

Would you be open to receiving a PR for a new tab ui that allows for the management of git worktrees?

https://www.youtube.com/watch?v=2uEqYw-N8uE

---

At a high level I imagine it would look kinda like:

• list of worktrees
• [a] add a worktree
  • panel prompt: name
  • panel prompt: branch
• [r] remove a worktree
  • fail if current
• [o] open a worktree
  • reload current window into worktree, or
  • a new window if settings.openWorkTreeInNewWindow == true

[kaste]

Yes, support for worktrees is on the wishlist.

It is important to have new commands which integrate into what we already have

For example,

• you look at a "random" commit (for example in the Repo History) for inspection and then want to quickly and temporarily check the whole tree/project out. (for testing and reading)

• in the branches dashboard, you create a new branch and decide to work on it on a worktree

• or you receive and see a new remote branch and choose "checkout as local branch but as worktree" (and open in a new window)

• the branches dashboard should show if a branch is checkout as a worktree (can we delete such branches and git will cleanup proper?)

Does git rmdir the worktree directories btw; or do we have to do this?

• the status dashboard should show that we're not in the main worktree; (offer to open the main worktree) (offer to close and delete this temporary worktree and switch to the main worktree)

Very quick implementation tips:

• do not introduce a new setting: both switch to worktree and open worktree in new window should be available without turning a setting. (open in new window is the more basic one of the two)

• if possible look at the core/interfaces/status.py implementation (mostly) because it is the only one atm which is completely async implemented.

• also if you implement a new WindowCommand (which you likely need to) use GsWindowCommand as used for example in core/commands/branch.py because it is also the newer abstraction.

[airtonix]

I need this workflow. I'll start looking into it and work on getting to fit your guidelines.

[airtonix]

the branches dashboard should show if a branch is checkout as a worktree (can we delete such branches and git will cleanup proper?)

> git worktree list
/home/zenobius/Projects/Mine/Github/GitSavvy  7eb2ae4e [feature/1601-git-worktrees]

we could at least use a pattern to get the branch name there and test if a branch is already checked out as a worktree. Then if the user tries to check it out, we just offer to open a new window with that worktree dir as the cwd. (not sure if sublime can know about other running instances of sublime and switch to an existing one?)

Does git rmdir the worktree directories btw; or do we have to do this?

removing a worktree can be done two ways:

• the git worktree remove <path-to-worktree>, or
• rm <path-to-worktree>; insert-complicated-sed-operation-over something in .git/???

the status dashboard should show that we're not in the main worktree; (offer to open the main worktree) (offer to close and delete this temporary worktree and switch to the main worktree)

"main" worktree is not a thing. There's only :

• the worktree you're on now,
• other worktrees git worktree list.

This is more obvious when you do :

git clone --bare some.repo.git ~/Projects/some-repo/.git
cd ~/Projects/some-repo
# add to .git/config
# [remote "origin"]
#     fetch = +refs/heads/*:refs/remotes/origin/*

git worktree add ./main master
git worktree add ./pr-review feature/UI-7933-add-employee-to-payrun
git worktree add ./payroll-staging release/payroll-1.17.2
git worktree add ./payroll-prod release/payroll-1.10.1

Now, you see the concept of a "main" worktree is entirely up to me to define.

[airtonix]

@kaste Should i make a new git_mixins/worktrees.py ? or would you like all the worktree commands to be part of the git_mixins/branches.py ?

[kaste]

Now, you see the concept of a "main" worktree is entirely up to me to define.

Haha, sure if you do a bare clone to begin with. In all other cases the main worktree is created by clone or init. Non-bare is still the typical case.

the branches dashboard should show if a branch is checkout as a worktree

For the branches dashboard, we basically only use a for-each-ref call and visualize this. You need to enhance the Branch tuple see: https://git-scm.com/docs/git-for-each-ref#Documentation/git-for-each-ref.txt-worktreepath

Since you cannot checkout a branch already checked out in a worktree it sounds reasonable to open it in a new window; or switch to it if already open. Also it may make sense that [d]elete means delete this worktree and not just the branch because we cannot delete a branch checked out somewhere else as a worktree.

Unfortunately, we cannot list detached worktrees with just for-each-ref. And a worktree can get detached quickly, for example in rebase session, on merge conflicts of any kind.

I'm not so sure about the concrete workflows.

Should i make a new git_mixins/worktrees.py ?

Typically yes, but you're also asking me to micro-manage here. The code and the commits should be reasonable and fit into what we have.

[kaste]

Switching and opening known worktrees is like switching known sublime projects. It is actually not really important to reimplement this here as we already have that with Sublime Text.

For example I now have

T.i. just creating a worktree and then open it once enables switching and reopening for free. (The exact panel in the picture above is self-made, but Sublime comes with a project switcher, it is just harder to read.)