Skip to content

About the worktree improvements in 2.17 #2735

@confusedsushi

Description

@confusedsushi

I really appreciate that there is work done on the integration of git worktrees in Fork. However I have some notes on it.

To my taste worktrees are now presented way to prominent. To list the worktrees at the beginning of the side bar move the view away from the important stuff for the current worktree.

Per repository I have often some more worktrees, maybe around 20 to 30. There is often a worktree for past releases and there are worktrees for long running feature implementations.

I organized the workspaces in a way that each workspace contains only tabs for worktrees of the same repository.

Now the tabs are prepended by some string to identify the workspace. Because for my workflow, all tabs in workspace are belonging to the same worktree, that information is not necessary, in fact it adds redundant information which is hiding the view for the important stuff.

The I can not really follow the way how worktrees are named. Somehow the directory of the worktree forms the leaf node, but for my use case worktrees often live in the directories which equal names, e.g., /source/version_A/repo/ and /source/version_B/repo/.

For the sidebar I suggest to have the order configurable. For the worktrees itself and the tabs I personally would prefer labels based on the worktree directory only.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions