Stacked branches

[adrian-gierakowski]

I often work on a feature branch and dispatch jobs to multiple agents into worktrees created from with that feature branch as base. I'd like to be able to see the git info (diff, commits ahead\behind etc) for these worktrees against that branch instead of default one

wt list could take --base argument
wt switch does take --base, but not in the interactive mode

[worktrunk-bot]

Thanks for the suggestion! I searched the codebase and confirmed that neither wt list nor wt switch (interactive mode) currently supports overriding the comparison base.

Here's what I found:

• wt list: The "main…±" diff column and "main↕" ahead/behind column are both hardcoded to compare against the default branch (main/master). There's no --base flag or config option to override this.
• wt switch --base: The --base flag exists but is restricted to direct mode with --create (for specifying the starting point of a new branch). It's not passed through to the interactive picker at all.

So both parts of the request — wt list --base <branch> and --base in interactive wt switch — would be new functionality.

I'll leave it for a maintainer to evaluate and prioritize.

[max-sixty]

Stacked branches could be v interesting; it would be a fairly big change though, so we'd need to think a lot how broad to make it — whether to encode this in the worktree data / allow passing at CLI / etc...

[worktrunk-bot]

Cross-posting from #1637 — a post-start hook can capture the base branch today using existing features:

post-start = [
  "wt config state vars set base_branch='{{ base }}'",
]

After that, {{ vars.base_branch }} is available in all future hooks for that worktree. A merge alias could reference it:

[aliases]
merge-base = "wt merge {{ vars.base_branch }}"

Limitations:

• Only works for worktrees created after the hook is added (no backfill for existing ones)
• If --base isn't specified, {{ base }} resolves to the default branch, so it'd store that — which is already the merge default, making it redundant in that case. It's most useful when --base is explicitly set to something else

[max-sixty]

also note https://github.com/pablospe/worktrunk-sync is related

[hc-greenventory]

Hey. I would also like to be able to not worry about which worktree got created from which base.

It would be nice if the base of a worktree would be (stored somewhere, is it stored somewhere?) and taken into account by wt step rebase so that my stacked branch is not merged into the default branch.

[worktrunk-bot]

No, the base isn't stored natively today — --base is consumed at create time and not persisted on the worktree. The post-start hook recipe above is the workaround: it captures {{ base }} into vars.base_branch so later commands can read it back.

For wt step rebase specifically, the command already takes a positional target (wt step rebase <target>, defaults to the default branch), so the same recipe threads through:

[aliases]
rebase-base = "wt step rebase {{ vars.base_branch }}"

Same caveats as before — only worktrees created after the hook is added get the variable, and you'd need to set it explicitly when --base matches the default branch. Whether the base should be stored natively (and respected by wt merge / wt step rebase automatically) is the bigger design question @max-sixty flagged.