[potsrevennil]

gco <branch> -q (or any flag) bypassed the checkout wrapper, so git refused with fatal: '<branch>' is already used by worktree. The wrapper only handled the bare git checkout <branch> form. There was also no short way to get git's own behavior from gco/gsw, since command git doesn't work with aliases.

Flags that only change how a switch runs are now set aside and passed to the switch the wrapper runs: -q/--quiet, --progress/--no-progress, -m/--merge, -f/--force, --discard-changes, -t/--track[=…]/--no-track, --guess/--no-guess, --recurse-submodules[=…]/--no-recurse-submodules. They're dropped when the wrapper only cds into the worktree that has the branch, since nothing switches there. Anything that changes what checkout does (-b/-c/--orphan, --detach, -p, -, paths) still goes straight to git, with its original arguments in their original order.

--vanilla before -- runs plain git minus the flag: gco --vanilla feat. Git rejects --vanilla too, so it fails safely if the wrapper isn't loaded, the same reasoning as -..

• Look at: the plain vs rest split in git(). rest (flags removed) decides whether the wrapper applies; every hand-off to git uses plain (original arguments minus -.).
• Worth knowing: -f reaches the switch wherever it happens. From a linked worktree, gco -f dev force-switches the main checkout and discards its local changes, as git's -f would there.
• Verify: a scratch-repo script covering 32 cases passes. The 22 earlier cases are unchanged, and the new ones cover -q with a branch held elsewhere, quiet switches in the main checkout and with -., --vanilla reproducing git's refusal, -b and -q -b hand-off, -f reaching the main checkout, -q -- <path>, and --vanilla as a path after --.

🤖 Generated with Claude Code