git flow <type> update <name> (and the top-level git flow update) checks
the named branch out directly on whatever repo the command was invoked from,
with no worktree awareness at all — unlike finish/delete, which gained a
redirect mechanism for exactly this in #175/#245. Naming a branch that has
its own separate linked worktree, from anywhere else, fails with a raw git
error instead of either redirecting or refusing cleanly.
Steps to Reproduce
git flow feature start my-feature --worktree (creates a separate
worktree for the branch, leaving the main worktree elsewhere)- From the main worktree (not the feature's own):
git flow feature update my-feature
Expected Behavior
Either the update runs correctly against the branch's own worktree (a
redirect, mirroring finish), or it refuses cleanly with an actionable
message naming the worktree.
Actual Behavior
Error: failed to checkout branch 'feature/my-feature': failed to checkout branch: exit status 128
Exit code 3 (generic Git error), not one of the validation exit codes the
rest of the worktree-aware commands use.
Notes
Found during the from-scratch audit that also produced #245's later fixes,
as the one bounded follow-up check explicitly scoped alongside that PR
rather than folded into it. internal/update.UpdateBranchFromParentWithMessage
is shared by both the standalone update command and finish's own
child-branch auto-update step — finish never hits this gap because it
redirects to a safe worktree (and, since #245's holistic-audit fixes,
refuses up front if an auto-update child has a conflicting worktree of its
own) before calling into it. The standalone command has no equivalent
guard.
The common case — running update from inside the branch's own worktree,
or with no worktree involved at all — is unaffected; this only surfaces
when naming a branch checked out somewhere else.
git flow <type> update <name>(and the top-levelgit flow update) checksthe named branch out directly on whatever repo the command was invoked from,
with no worktree awareness at all — unlike
finish/delete, which gained aredirect mechanism for exactly this in #175/#245. Naming a branch that has
its own separate linked worktree, from anywhere else, fails with a raw git
error instead of either redirecting or refusing cleanly.
Steps to Reproduce
git flow feature start my-feature --worktree(creates a separateworktree for the branch, leaving the main worktree elsewhere)
git flow feature update my-featureExpected Behavior
Either the update runs correctly against the branch's own worktree (a
redirect, mirroring
finish), or it refuses cleanly with an actionablemessage naming the worktree.
Actual Behavior
Exit code 3 (generic Git error), not one of the validation exit codes the
rest of the worktree-aware commands use.
Notes
Found during the from-scratch audit that also produced #245's later fixes,
as the one bounded follow-up check explicitly scoped alongside that PR
rather than folded into it.
internal/update.UpdateBranchFromParentWithMessageis shared by both the standalone
updatecommand andfinish's ownchild-branch auto-update step —
finishnever hits this gap because itredirects to a safe worktree (and, since #245's holistic-audit fixes,
refuses up front if an auto-update child has a conflicting worktree of its
own) before calling into it. The standalone command has no equivalent
guard.
The common case — running
updatefrom inside the branch's own worktree,or with no worktree involved at all — is unaffected; this only surfaces
when naming a branch checked out somewhere else.