A background session starting in its recorded worktree now adopts and locks it.
What's wrong with this entry?
A background session whose recorded worktree path is the directory it starts in now adopts that worktree instead of ignoring it: it checks the git root, takes a worktree lock, retries once after 250 ms, and records the state. If any of that fails it logs a warning and carries on rather than aborting startup.
- Only runs when the session has a worktree path and the worktree was not created by a hook, plus several repository checks.
[worktree] bg boot: adopted ${e} but no worktree lock names this process
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.222
Resuming into a missing or unverifiable worktree is now explained
Both mention worktree
-
v2.1.222
Worktree creation validates the resulting root before use
Both mention worktree
-
v2.1.239
worktree.locationsetting for Desktop SSH sessionsBoth mention worktree