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 859ddf3c7663bed8cf913f761f1063dda56e9e89

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.

[quincunx]

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.

Another great Git GUI with worktree support is:

• SmartGit

[kikeenrique]

After using git worktree for some weeks and using fork as UI I've detected this problems:

• Fork does not see other worktrees (as this feature request asks)
• In order to open a worktree it's needed to go to the folder where the worktree is located and via CLI launch fork from that directory.
• "Show in finder" does not work for worktrees.

[DanPristupov]

@kikeenrique

In order to open a worktree it's needed to go to the folder where the worktree is located and via CLI launch fork from that directory.

You can use Cmd+O as an alternative.

"Show in finder" does not work for worktrees.

It works for me. Check the log file for clues ~/Library/Logs/Fork.log or send it to support@fork.dev.

[kikeenrique]

@kikeenrique

In order to open a worktree it's needed to go to the folder where the worktree is located and via CLI launch fork from that directory.

You can use Cmd+O as an alternative.

Thanks, I forgot that.

"Show in finder" does not work for worktrees.

It works for me. Check the log file for clues ~/Library/Logs/Fork.log or send it to support@fork.dev.

Thanks for the log clue. I didn't see the problem clearly, in some worktrees it worked properly, but in others didn't. I've found a fix, apparently, which consists in closing the not working tab and opening again (from CLI, when opening it from cmd+O, "show in finder" does not work). I can only see one log line with a failure, but it seems to be not related. `❌[GetReferencesGitCommand.swift:89] > Cannot parse reference refs/original/refs/heads/fastlaneSwift

[DanPristupov]

@kikeenrique

from CLI, when opening it from cmd+O, "show in finder" does not work

Thank you, I'll check this.

We will also have a look if we can show workspaces on the sidebar.

[brokenthorn]

@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.

Work trees are basically separate checkouts of separate branches of the same repo, if I understood correctly.

What Fork I think needs to do is support them under the hood so it knows the edge cases that apply when issuing the usual git operations in a worktree versus a normal repo.

Visually, the functionality should be the same as with a normal repo. Perhaps it would be great if it could identify all worktrees of the same repo and perhaps add new roots to the top left "local changes" and "all commits" navigator.

to something like

HTH.

I've just stumbled across worktrees and was thinking about using them and came here to see if Fork supports them, so: I don't know if the repo name can still be identified, if not then probably just show worktree names. I don't know if worktrees can be identified either, because you can technically spawn them wherever. I don't know if worktrees are allowed to have branches.

[DanPristupov]

As an experiment, in the next update (Fork 2.31) we are going to add the list of existing worktrees to the sidebar:

[krin-san]

@kikeenrique

from CLI, when opening it from cmd+O, "show in finder" does not work

Thank you, I'll check this.

We will also have a look if we can show workspaces on the sidebar.

I have the same issue in Fork Version 2.33 with worktrees opened via CLI command fork. I have set up a "Branch Command" to automate creating worktrees which looks like that:

NAME="${repo:name}-$(echo ${ref:short} | tr '/' '\n' | tail -1)"
git worktree add -B "${ref:short}" ../"$NAME" ${ref}
fork ../"$NAME"

In the repo tab opened in Fork, "Open in Terminal" starts a shell correctly, in the worktree directory, but "Open in Finder" opens the main worktree directory instead – the one containing .git dir.

[brokenthorn]

As an experiment, in the next update (Fork 2.31) we are going to add the list of existing worktrees to the sidebar:

This is super awesome to hear, Dan! So very excited for this feature!

May I add something? Hopefully this is useful feedback. Worktrees are conceptually somewhat like checking out a branch inside a dedicated folder instead of in the main worktree, where you can only have one branch checked out at a time. This allows you check out multiple branches to separate folders and switch between more easily, without having to commit or stash WIP work.

Thus, to me they look like just branches, conceptually. So, I would really love to have worktrees live closer somehow to the branches on the sidebar. Either next to Branches or if you can find a way to integrated them somehow... like Branches to contain Worktrees? IDK?

Anyway, I'm sure whatever you do, it's gonna be awesome!

[andymac4182]

Just used this! So excited to see this coming :) I love worktrees and its one of the few things I still have to do in the CLI.

[DanPristupov]

@brokenthorn

Thank you for the feedback.

... to me [workspaces] look like just [branches], conceptually. So, I would really love to have Worktrees live closer somehow to Branches on the sidebar.

Conceptually the Workspaces section should be even above Branches because the worktrees concept is lying between working directory and branches. So, may be it should be the first item on the sidebar, right below the filter box.

Would that make the life better, though? It's a big change and I'm afraid of making something very wrong :).

@mtschoen-unity it would be great if you could share your point of view.

[brokenthorn]

@brokenthorn

Thank you for the feedback.

... to me [workspaces] look like just [branches], conceptually. So, I would really love to have Worktrees live closer somehow to Branches on the sidebar.

Conceptually the Workspaces section should be even above Branches because the worktrees concept is lying between working directory and branches. So, may be it should be the first item on the sidebar, right below the filter box.

I think you might be right... Let's hear more feedback though.

Would that make the life better, though? It's a big change and I'm afraid of making something very wrong :).

Yeah. It's a higher level abstraction

Repo name (virtual) / n workspaces (physical, in different folders / branches / commits

Is the above the correct hierarchy model?

[infotexture]

Conceptually the Workspaces section should be even above Branches because the worktrees concept is lying between working directory and branches. So, may be it should be the first item on the sidebar, right below the filter box.

That's true, but workspaces are a niche feature that even many Git experts don't use, so I'm not sure placing it first would make everyone happy.

It would probably be fine if it remains context-sensitive, so the the Workspaces section only appears if additional workspaces are defined (like it is now).

Of course, you could always allow users to change the order of sidebar sections (like in Finder, where you can drag and drop sections into the preferred order), but that's probably best treated as a separate issue.

[chucker]

Conceptually the Workspaces section should be even above Branches because the worktrees concept is lying between working directory and branches

Agreed. In terms of taxonomy, that makes sense to me. And since it only shows up if there are additional worktrees, it shouldn't confuse existing users much.

Having said that: the flipside is that this behavior (it showing up dynamically) seems to be unlike any other module. For example, submodules are also a bit rarely used, yet they always show up. And that's useful, because it's how you add submodules as well. (Whereas worktrees currently seem to be read-only in Fork.)

[brokenthorn]

@brokenthorn

Thank you for the feedback.

... to me [workspaces] look like just [branches], conceptually. So, I would really love to have Worktrees live closer somehow to Branches on the sidebar.

Conceptually the Workspaces section should be even above Branches because the worktrees concept is lying between working directory and branches. So, may be it should be the first item on the sidebar, right below the filter box.

Would that make the life better, though? It's a big change and I'm afraid of making something very wrong :).

@mtschoen-unity it would be great if you could share your point of view.

Sorry. I meant work trees, not workspaces. I don't use the workspaces feature in Fork (yet) at all. So I've always referred to Git work trees in this discussion, not Fork workspaces. Sorry for the confusion.

What you are saying about workspaces being above branches is totally correct. And yes, work trees are a concept between the working directory and branches.

Git has a concept of the default working directory, which is where you normally first check out your remote repository or where you initially init a git repo.

When you create a new git work tree, you create a folder that is akin to cloning your repository's main work tree, or akin to checking out (cloning) the same repository but in another separate folder, such that you can have different branches checked out in each of these folders, giving you the ability to have two "working trees" of the same repository, at the same time, and the ability for them to both have uncommitted changes, which is not something you can do with a single working tree (like the default one for example). You have to first discard your changes or commit them before you can switch to another branch.

So yeah, work trees are sort of in between: REPO / WORK DIR/TREE / ACTIVE BRANCH.

It's almost 4 AM here, so sorry if I made any mistakes. Thanks for listening!

[mtschoen-unity]

@mtschoen-unity it would be great if you could share your point of view.

Hey there! I did a skim of the thread but I want to make sure we're talking about the same thing. Is the question about where to put the new Worktrees section in this ui?

To be honest, I don't have much of a preference here. I don't tend to use that section at all, but instead I start with the worktree's representation in the Repositories or Recent list in the Repository Manager window. Staying at the bottom of the list would actually best fit my workflow. 🤷

[matheusamazonas]

Is it normal that, when a worktree is open, the remote branches are never displayed, neither on the sidebar nor on the commit history?

Edit: running git remote show origin does show all branches under the Local refs configured for 'git push' section.

[DanPristupov]

Is it normal that, when a worktree is open, the remote branches are never displayed, neither on the sidebar nor on the commit history?

Yes, if it's a working tree for a bare repo. Otherwise it's not.

[matheusamazonas]

Yes, if it's a working tree for a bare repo. Otherwise it's not.

That was the case. I just tested it with a non-bare repo and the remotes are there.

Just curious: is that a git or Fork limitation?

[DanPristupov]

Just curious: is that a git or Fork limitation?

It's git. I think bare repos are supposed to be used on servers and can't have other remotes.

[matheusamazonas]

For those who are interested in using bare repositories, this workaround that adds remote tracking and that works with Fork too.

[DanPristupov]

In Fork 2.41 we added the ability to create new workspaces from a local branch.

[krin-san]

Nice to see more and more features related to Git Worktrees. I have a couple of custom Branch and Repository scripts to create and delete worktrees making it an ideal feature to work on multiple tasks in parallel.

I kinda expected to find this 2.41 feature in a Branch context menu. It is an ideal place for such a feature because it is contextual – you already clicked on the branch you want to create a worktree for, but have to go the main menu instead and search this branch name again.

What do you think about adding "Add Worktree..." to the Branch context menu as well?