Question

While verifying the worktree icon checklist from #4994, I noticed that the icon shape used for worktree nodes differs between the two views. I want to confirm whether this is intentional design or a code inconsistency.

Observed behavior

Worktrees view — WorktreeNode.getTreeItem() (worktreeNode.ts:255):

icon = getBranchIconPath(this.view.container, branch);

→ Uses getBranchIconPath → renders the branch-graph shape icon
(e.g. icon-branch-ahead.svg, icon-branch-synced.svg)

Branches view — BranchNode when a worktree is associated (branchNode.ts:718):

iconPath = getWorktreeBranchIconPath(container, branch);

→ Uses getWorktreeBranchIconPath → renders the worktree shape icon
(branch fork + window, e.g. icon-worktree-ahead.svg, icon-worktree-synced.svg)

Result

The worktree-shaped SVG icons (the ones with the status dot variants described in the #4994 checklist section 4) only appear in the Branches view, not in the Worktrees view.

Additionally, getWorktreeBranchIconPath is called in BranchNode without passing a status parameter, so the blue-dot variant (icon-worktree-changes.svg, which requires status?.hasWorkingTreeChanges === true) is never reachable from either view with the current code.

Questions

1. Is it intentional that WorktreeNode (Worktrees view) uses branch-shaped icons while BranchNode with a worktree (Branches view) uses worktree-shaped icons?

2. Should WorktreeNode also use getWorktreeBranchIconPath to show the worktree-shaped icon with status dots, consistent with what the checklist in Raise minimum version to 1.101 #4994 describes for section 4?

3. Is the icon-worktree-changes.svg (blue dot, local changes) intentionally unreachable — or should status be passed to getWorktreeBranchIconPath in BranchNode to enable it?