Feature request: Support multiple working tree

[ppggff]

Support function as git worktree that manage multiple working trees attached to the same repository.

[DanPristupov]

Is there any public available repository with work trees, so I could see how this feature is used in a real project?

[ppggff]

This feature is mainly for local development. I use this function to work with different branches at the same time, each working tree for a different branch. Then I don't need to checkout to different branch every time, saving a lot of time for rebuilding and other stuff.

[hardkrash]

Agreed, worktree is a great feature.

It is entirely local, not something that would be seen on a git server.

To try it out on this project

git worktree add ../fork_issues_worktree 859ddf3

Will make a worktree in your parent directory pointing to that commit.

[k3n]

Yeah, was looking forward to using this app, but without worktree support it does me no good -- it doesn't find any of the worktree repos.

[eugioc]

+1 for feature request for support for worktrees. It's such a useful git feature.

[natronite]

Every time I rescan a folder for repositories it removes the ones I added through git worktree. The thing is that the worktree folders don't contain a .git folder but a .git file.

[mariusmarais]

My team use worktrees heavily for local development, I'm putting my usage here for reference and comment by others.

I clone projects into folders as follows (but there is no actual structure requirement in git itself):

~/projects
  - project1
    - repo (usually master)
    - feature1 (marius/feature1)
    - featute2 (marius/feature2)
  - project2
    - repo (usually master)
    - feature1 (marius/feature1)

While this works, Fork sees every directory as a different repo, which confuses things. However, it makes the Fork recent items almost useless, since everything is called "repo" or "feature1". Usually with a frontend and backend project on feature branches with the same name, it gets confusing, which is why I'm mostly using Terminal to launch Fork from the directories.

I think worktree support along the following lines would be quite useful:

• If usage of worktrees is detected, determine the project name in a different way, by maybe looking at the parent directory or using a custom alias in .git/config?
• For each worktree, show it somewhere under the project browser, BUT
  • Use the same interface window for all worktrees since they have the same history (this works well right now)
  • Under "Local Changes", list separate worktrees, with their own local changes underneath.
    That would allow worktree navigation to be a lot more intuitive.

Actually creating new worktrees and so on would be nice, but this happens a lot less often than browsing, committing and so on, so I don't think that would be necessary for the main interface. Especially considering that anyone using worktrees has already figured out how to create one :)

Using worktrees one is also less likely to switch a specific worktree to a different branch, you simply create a new one.

[laurentvaills]

I also use worktrees locally to checkout some branches besides my main directory.
But unfortunately when I do so, I can't use Fork on this new directories and have to go back (and remember) the git command line.
The "add interactive" is much easier through Fork rather than the command-line.

If also I could select a branch in Fork and select "Checkout in an other directory" or so that would be really nice.

[mariusmarais]

@laurentvaills you can actually use Fork to stage & commit, I do so every day...

Just:

$ cd ~/worktree
$ fork .

And Fork will open it as a "new" repository, sharing history with the main repo. You can have multiple worktrees open at the same time like this. The repo browser window gets a bit confused but it works well enough if you always (mostly) use the CLI to launch.

[mariusmarais]

Explained worktrees to some new colleagues recently, and came to check up on this issue...

Separating out a folder for each worktree under "Local Changes" would really make a world of difference.

[DanPristupov]

@mariusmarais

Separating out a folder for each worktree under "Local Changes" would really make a world of difference.

The active branch and commit also differ. I think you should open both worktrees in separate tabs.

[mariusmarais]

Yes @DanPristupov, you're right. They could be shown as a different type of label in the history, and could be shown in the "folder" as a label, since that's where they apply.

But this is why "just" doesn't belong in feature requests, because it's never quite that simple.

[infotexture]

ℹ️ For details, see https://git-scm.com/docs/git-worktree.

I use worktrees all the time and find them very handy. While Fork doesn't detect worktrees from the main repo, it works fine if you switch to the worktree directory via the CLI as @mariusmarais suggested (or via File > Open, or File > Open Recent).

In this case, Fork shows all the parent repo's branches, tags, and stashes in the worktree repo window, so you can see everything in one place.

Would be nice to teach Fork how to “see” related worktrees from a parent repo and represent them in the sidebar somehow.

@DanPristupov The UI support could build on the approach for submodules, so there'd be an extra Worktrees section in the sidebar (below Tags, Stashes, & Submodules), with commands to add/delete worktrees, and maybe warn you if you delete a branch that's checked out in a worktree.

Double-clicking a linked worktree in the sidebar could open the worktree folder in a new Fork window, just like with submodules:

Worktrees

• 🔗 feature1
• 🔗 feature2

[kikeenrique]

I would love to see some support for worktree in fork.

I've done some research to find git UIs supporting worktree and there are not many. I've found:

• gitlens, with a small preview in https://www.gitkraken.com/gitlens/plus-features

• tortoisegit, without a preview https://tortoisegit.org/docs/tortoisegit/tgit-dug-worktrees.html

I like the approach comment by @infotexture, having another sidebar like submodules.