Skip to content

v0.11.2

Latest

Choose a tag to compare

@github-actions github-actions released this 27 Oct 10:37
Immutable release. Only release title and notes can be modified.
e43b135

This is a fixes-only release for worktrees. A new branch now starts from the merge branch as the remote has it, never from a local copy that has fallen behind. Two worktree checks that missed cases now catch them: a branch in use on macOS, and unpushed work on a branch with no upstream.

A new branch starts from the remote's merge branch

Until now, lets worktree create without --base cut from the local LETS_MERGE_BRANCH. If the local main was behind origin/main, the new worktree started without the latest merged work. A git fetch did not help, because it moves origin/main and not main. lets worktree switch had the opposite problem: it needed a remote literally named origin, and refused in a repository with no remote at all.

Every implicit cut now goes through one base policy in Go. That covers lets worktree create, lets worktree switch, Orca's open and team-create, and take-task's Branch pick:

  • Which remote: the merge branch's upstream remote, else the only configured remote, else origin.
  • Which commit: <merge> is fetched with a time limit, and the branch is cut with --no-track from exactly that commit.
  • Fetch fails: the cut uses the last fetched copy and says how old it is. Local commits that are missing from the base are named in a warning.
  • No remote configured: the base is the local <merge>, and the run says so.
  • Refusals: a remote without <merge> refuses with exit 31 no_remote_base. Several remotes with none chosen refuse with exit 31 remote_ambiguous.

An explicit --base behaves exactly as before. lets worktree base --json shows how the base was resolved, and the create, switch and Orca envelopes report the same as base_resolution. The branch-cut steps in the command specs no longer run their own git fetch, so none of them needs a timeout binary. macOS does not ship one.

A branch in use is reported on Apple git 2.39

lets worktree create now checks git worktree list before it runs git worktree add. Apple git 2.39 is the macOS default. On it, a branch checked out in another worktree now gets exit 13 branch_in_use_other_worktree, which names that worktree. Before, it got a generic exit 16. Both git phrasings are still recognized, for when another process takes the branch between the check and the add. With this fix the release gates pass on a stock macOS host for the first time, with no test skipped.

Unpushed work is caught without an upstream

New branches no longer get an accidental upstream of origin/<merge>. With push.default=upstream, a plain git push would have gone straight to the merge branch. Without that upstream, lets worktree remove can no longer rely on @{u}, so it now counts the branch's commits that no remote holds. A branch with no upstream and such commits refuses with exit 21, just as an unpushed branch with an upstream always did. In a repository with no remote, nothing is ever pushed, so the check is skipped with a warning.

Upgrading

Run /lets:update, then restart the session. No configuration changes. A script that expected exit 16 for a branch in use on macOS now gets exit 13, the same as on Linux.