New worktree interface behaves erratically for primary repo/worktree

[dineshm72]

using fork win 2.18.0.0

I have the following worktree setup:

I'm not sure if this occurs all the time for any repo where you've added a worktree, or only if you had previously manually created a worktree specifically for the main tracking branch (which I had done, using the previous iterations of Fork), but once you have more than one, windows fork seems to start behaving inconsistently when dealing with the main branch / top level worktree.

If you are in a separate linked worktree, you cannot (create a new tab for it if needed, and then) switch to the main branch worktree by double clicking the main branch (like you can for any other worktree), it brings up this error.

Right clicking a branch associated with a linked worktree brings up the option to switch to it, like so:

But right clicking the main branch does not give you that option, even though it is also associated with a worktree:

In fact, the only way you can now actually switch back to the master branch as far as I can tell is to right click on the worktree associated with it in the worktree section of the side bar and click to open it there:

--

Another inconsistency is whether the main branch worktree is even shown in the worktree section. When you are in another worktree it appears there (and shows as a higher level "folder" object for the other linked worktrees), as in the screenshot above. However, once you have actually opened that main branch worktree, it no longer displays itself in the worktree listing:

Additionally, the tab opened for the main worktree just shows the main repo name, as it would if no worktrees had been created, and unlike what it shows for any linked worktree (which show as repo name: worktree name).

It is worth noting, in case it is relevant, that all my worktrees are physically located at the same folder level in the filesystem as the main repo. I had started that convention before the most recent update, which now seems to default to placing them in a worktrees subdirectory. Fork didn't seem to have any problem continuing to create them in this way, but I thought I would mention it in case it were somehow relevant to the behavior seen above.

[dineshm72]

As an aside, in previous versions with worktree support, I am pretty sure you could create a new worktree for an existing branch from the Repo - New Worktree dialog (in fact, it's possible you had to do this, I can't recall for sure if you could do it from the sidebar too). In the resulting dialog, any branch that was already associated with a worktree was grayed out, and you HAD to pick one not yet associated with a worktree (which I think also included the main default branch, unless and until you manually created a worktree for it, as I have done above).

I think you revamped this process as part of the latest worktree enhancements. Now that dialog can only be used to create a new branch and worktree it. This is fine for new feature development, but doesn't really match my needs, where I just need to be able to define separate directories for various existing and tracked branches for local testing. So I was very confused and frustrated that this dialog now seems to require creating a new branch in its workflow.

It took me a bit to realize that to do what I needed, you now have to right click on the branch in the sidebar and click to create the worktree from that branch there. I have no problem with the workflow itself, it makes sense. But it's different from what was possible before, and it's not exactly clear to the end user why there are two different ways to create worktrees and how they are different. Ideally both methods would allow for both types of new worktrees. At a minimum, it would have been great to have some warning or documentation about the changes! Thanks!