Skip to content

Searchable base-ref picker in the New Worktree dialog (#387)#411

Open
webdevtodayjason wants to merge 2 commits into
supabitapp:mainfrom
webdevtodayjason:feat/base-ref-filter
Open

Searchable base-ref picker in the New Worktree dialog (#387)#411
webdevtodayjason wants to merge 2 commits into
supabitapp:mainfrom
webdevtodayjason:feat/base-ref-filter

Conversation

@webdevtodayjason

Copy link
Copy Markdown
Contributor

What

Closes #387. The Base ref selector in the New Worktree dialog was a hierarchical Menu (Local submenu + per-remote submenus + nested namespace submenus). Finding a deeply-namespaced branch meant remembering its prefix and drilling submenus — e.g. to branch off feature/jira-1234/core-refactoring you had to recall jira-1234 and whether it was local or remote.

Change

Replace the nested menu with a popover that filters a flat list of local + remote refs as you type:

  • Matches any fragment of the full ref (remote, namespace, or leaf), case-insensitive — so typing core-refactoring jumps straight to feature/jira-1234/core-refactoring.
  • Keeps the Auto and default-branch (Local) quick picks pinned at the top.
  • Filter field auto-focuses on open; selecting a ref sends the existing baseRefSelected action and dismisses.

The filtering is implemented as pure helpers on BaseRefBranchMenu (allRefs() / refs(matching:)), so the view is a thin renderer. The now-unused nested-menu helper views are removed.

Tests

BranchMenuFilterTests covers the flatten, the deep-fragment match (#387's scenario), case-insensitivity across remotes, a namespace segment that's also a branch (release + release/v2), and the no-match case.

Note on verification: filter logic is covered by the new unit tests; I confirmed the changed files lint clean. I couldn't run the app to eyeball the popover locally (zig 0.15.2 won't link the macOS 26.5 SDK on my machine), so a quick visual sanity-check of the popover sizing/placement would be appreciated.

…pp#387)

The base-ref selector was a nested Menu: to branch off
feature/jira-1234/core-refactoring you had to remember the jira-1234
prefix and drill local/remote submenus.

Replace it with a popover that filters a flat list of local + remote refs
as you type, matching any fragment of the full ref (remote, namespace, or
leaf) case-insensitively. The filtering lives in pure, tested helpers on
BaseRefBranchMenu; the view is a thin renderer and the old nested-menu
helper views are removed.

Adds BranchMenuFilterTests covering the flatten, deep-fragment match,
case-insensitivity, namespace-also-a-branch, and no-match cases.
@sbertix

sbertix commented Jun 18, 2026

Copy link
Copy Markdown
Collaborator

Ideally we'd keep both, because the menu is significantly more practical in larger teams/OSS where you don't necessarily know the name of the repo in advance.
I was thinking more of having the text input inline and either a popover (if we can easily juggle keyboard arrows) or even just a set of rows (even just 1 row with fake "subrows" inside it) being added below it. Would you be interested in iterating on this?

Per review: the hierarchical menu is the better tool when you don't know the
branch name in advance, so keep it. Add an inline filter field beside it that
lists matching local + remote refs as rows below as you type — no popover and
no keyboard-focus juggling. Filtering still runs through the tested
BaseRefBranchMenu.refs(matching:) helper.
@webdevtodayjason

Copy link
Copy Markdown
Contributor Author

Love it — yeah, keeping the menu totally makes sense. Browsing is the right move when you don't know the branch name up front, no argument here. 🙌

Just pushed an update that does exactly that: the hierarchical menu stays put for browsing, and there's now an inline filter field right next to it. As you type it drops the matching local + remote refs in as rows right below the field (went with your "set of rows" idea so there's zero keyboard-focus wrestling). Capped it at 8 with a little "keep typing to narrow" nudge so the dialog doesn't blow up.

Filtering still runs through the same tested BaseRefBranchMenu.refs(matching:) helper, so the menu and the search share one source of truth.

I went rows-first to keep it simple and shippable, but I'm totally down to layer arrow-key nav + the popover route on top next if you wanna get fancy. Lmk what you think! 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Feature request: Search in Base ref in New worktree dialog

2 participants