Skip to content

Apply worktree layouts on worktree.opened too (fixes intermittent no-op)#25

Merged
cloudmanic merged 1 commit into
mainfrom
worktree-opened-event
Jun 16, 2026
Merged

Apply worktree layouts on worktree.opened too (fixes intermittent no-op)#25
cloudmanic merged 1 commit into
mainfrom
worktree-opened-event

Conversation

@cloudmanic

Copy link
Copy Markdown
Owner

The bug

Worktree auto-layout worked intermittently — sometimes a new worktree got its tabs, sometimes nothing happened.

Root cause: herdr has two worktree events, and we only subscribed to one.

  • worktree.created — fired when herdr creates a brand-new worktree.
  • worktree.opened — fired when herdr opens an existing worktree into a workspace (e.g. the right-click dialog for a branch that already has a worktree).

We only listened for worktree.created, so opening an existing worktree silently skipped the layout — no handler invocation at all in the plugin log.

The fix

  • Subscribe to both worktree.created and worktree.opened, sharing one handler (on-worktree-createdon-worktree, runOnWorktreeCreatedrunOnWorktreeEvent).
  • Idempotency guard: skip a workspace that already holds more than one pane, so a layout never applies twice — even if both events fire for one workspace or herdr reopens an already-populated one. (A freshly created/opened worktree workspace has exactly one root pane.)
  • Fix a stale herdr-plugin.toml comment that still referenced the removed enabled toggle.
  • Docs: note both events, and that worktrees must be created/opened through herdr (plain git worktree add / lazygit don't fire herdr events).

Verified live against herdr 0.7.0

Using herdr plugin link of this branch:

Action Events fired Result
worktree create (new) worktree.created ×1 layout applied once
worktree open (existing) worktree.opened ×1 layout applied (previously skipped)
create confirmed it does not also fire opened (no double-apply)

go build, go test, and go vet all pass.

herdr fires worktree.created only when it creates a brand-new worktree; opening
an existing worktree into a workspace (e.g. the right-click dialog for a branch
that already has a worktree) fires worktree.opened instead. We only subscribed to
created, so opening an existing worktree silently skipped the layout — which read
as the feature working intermittently.

Subscribe to both events, sharing one handler (renamed on-worktree-created ->
on-worktree, runOnWorktreeCreated -> runOnWorktreeEvent). Add an idempotency guard
that skips a workspace already holding more than one pane, so a layout never
applies twice even if both events fire for the same workspace or herdr reopens an
already-populated one. Verified live against herdr 0.7.0: create fires exactly one
event and applies once; open now fires and applies; back-to-back open of a
populated workspace is skipped.

Also fixes a stale herdr-plugin.toml comment that still referenced the removed
enabled toggle, and documents that worktrees must be created/opened through herdr
(not plain git) for the events to fire.
@cloudmanic cloudmanic merged commit 3464670 into main Jun 16, 2026
2 checks passed
@cloudmanic cloudmanic deleted the worktree-opened-event branch June 16, 2026 17:49
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.

1 participant