Repository navigation
Show a worktree's full path on hover to tell apart worktrees with the same folder name #22946
Agent suggestions
Public previewDescription
The feature request
The worktree dropdown labels every worktree by the basename of its path (getWorktreeDisplayName). When several linked worktrees share a folder name, they are indistinguishable. This is common when tooling creates one checkout per workspace under the same relative name, e.g. ~/projects/a/.work, ~/projects/b/.work, ~/projects/c/.work: the "Linked Worktrees" list shows a column of identical .work entries, and the toolbar button tooltip only says "Current worktree is .work".
The existing name tooltip does not help, because it repeats the same basename and only appears when the name overflows.
Proposed solution
Show the worktree's full path on hover:
- In the worktree list, the name tooltip shows
worktree.path, always, not only when the name overflows. - The toolbar button tooltip reads "Current worktree is ".
This keeps the compact basename label and needs no layout change. It follows the tooltip conventions already used in the list item (the tooltips stay disabled under the accessible-list-tooltips flag, as today).
I have a small change ready (two lines across worktree-list-item.tsx and worktree-dropdown.tsx) and am happy to open a PR if this is marked help wanted.
Additional context
Reproduction: create several linked worktrees whose directories share a basename (git worktree add ../x/.work, git worktree add ../y/.work), then open the worktree dropdown.
Activity
desktop-triage commentedon Sep 29, 2026
Classification: Enhancement
This is a clear feature request describing current behavior (worktree names truncated to basename, causing indistinguishable entries when multiple worktrees share a folder name) and a proposed fix (show full path on hover). It is closely related to #22375 (worktree search should use more than the basename to distinguish worktrees) but targets a different surface — hover tooltips versus search/filter matching — so I'm treating it as related rather than a duplicate. It is not a duplicate of #22650, which is about a missing row-level tooltip fallback when accessible list tooltips are enabled, a distinct gap in the same component. Note the issue is already linked to an open PR (#22947).
Initial hypothesis: The symptom traces directly to how the worktree name and tooltip are built today. In
worktree-list-item.tsx#L24-L37,namecomes fromgetWorktreeDisplayName(worktree)(the path basename) and theTooltippedContentwrapping it setstooltip={name}withonlyWhenOverflowed={true}— so the tooltip repeats the same basename and only appears once the label overflows, never showing the differentiating full path. Similarly, inworktree-dropdown.tsx#L150-L161,titleisPath.basename(currentWorktree.path)and the toolbar tooltip isCurrent worktree is ${title}, again only the basename. Both confirm the reporter's described root cause, and the fix (switching the tooltip source toworktree.pathand removingonlyWhenOverflowed/adjusting the toolbar tooltip text) is a small, localized change, consistent with the reporter's claim of a "two lines across" fix and the linked PR #22947.Show and search worktree paths
Show and search worktree paths
Show and search worktree paths