Skip to content

feat(worktree): apply the layout when opening an existing worktree - #31

Open
nilp0inter wants to merge 2 commits into
andrewchng:mainfrom
nilp0inter:feat/worktree-layout-on-open
Open

feat(worktree): apply the layout when opening an existing worktree#31
nilp0inter wants to merge 2 commits into
andrewchng:mainfrom
nilp0inter:feat/worktree-layout-on-open

Conversation

@nilp0inter

Copy link
Copy Markdown
Contributor

Problem

Opening an existing worktree (via the worktree-open action) leaves Herdr's default single-shell workspace, while creating a worktree bootstraps the configured tab layout. The two paths are inconsistent: opening a previously checked-out worktree gives a bare shell instead of the user's layout.

Solution

Add an opt-in [worktree].layout_on_open config. When enabled, the three "open existing worktree" paths in the worktree flow run the same createProjectLayout bootstrap that creation uses (resolving the checkout cwd, honoring repo-local .sessionizer/config.toml overrides, then focusing):

  • the open-worktree intent (an existing checkout picked from the candidate picker)
  • the first worktrees.open attempt in openOrCreateWorktree (the branch already has a worktree)
  • the resolver fallback that opens an existing checkout after create fails

The open-workspace intent (focusing a workspace that already exists) is intentionally left untouched — it may carry user state.

The shared logic lives in a new bootstrapOpenedWorktree helper; bootstrapWorktree gains a verb so the success log reads "opened and focused" vs "created and focused".

Default

Follows the git_only precedent from 0.5.1:

  • existing configs: layout_on_open omitted → false (current focus-only behavior, non-breaking)
  • newly generated configs: [worktree] layout_on_open = true

Happy to flip the missing-field default to true if you'd prefer open and create to be consistent out of the box — the gate makes either trivial.

Tests

  • config: layout_on_open defaults to false in existing configs, true in generated configs, and parses from [worktree]
  • worktree flow: layout applied when opening an existing worktree with the gate on (picker path, asserting exact createLayout args; and CLI --project --branch path)

bun run typecheck and bun test (140 passing) are green.

Docs

CHANGELOG (Unreleased), README config field reference + layout-source table, and the sessionizer-layout-editor skill bootstrap note/scope.

Opening an existing worktree checkout previously left Herdr's default
single-shell workspace, while creating a worktree bootstrapped the
configured tab layout. Add an opt-in [worktree].layout_on_open config
that runs the same layout bootstrap when a worktree is opened from the
candidate picker or by project and branch.

The field defaults to false so existing configs keep the current
focus-only behavior; newly generated configs set it to true.
Add a CHANGELOG entry under Unreleased, the README config field
reference plus layout-source table rows, and update the
sessionizer-layout-editor skill bootstrap note, global scope, and
examples.
@andrewchng

Copy link
Copy Markdown
Owner

Thanks — the three open-checkout paths and leaving open-workspace as focus-only look right.

Direction change: drop [worktree].layout_on_open. Layout should always run for checkout-only open (same as create). Live workspace reattach stays focus-only, no config.

  • Remove the flag from config, default TOML, README, and skill docs.
  • Always bootstrap layout on the open-checkout paths; keep tests that open-workspace never calls createLayout.
  • Upgrade is a mild behavior fix (open matches create), not a real break.

Conflicts: PR currently conflicts with main — please rebase/resolve (especially CHANGELOG.md) before re-review.

Changelog: yes, keep an Unreleased entry; reword after dropping the flag, e.g. “Opening an existing worktree checkout now applies the tab layout (same as create). Focusing an existing Herdr workspace is unchanged.”

Happy to re-review after that.

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.

2 participants