docs(switch): say why a branch off a remote base has no upstream - #3913
docs(switch): say why a branch off a remote base has no upstream#3913worktrunk-bot wants to merge 2 commits into
Conversation
worktrunk-bot
left a comment
There was a problem hiding this comment.
The behavior claim is right — switch.rs unsets the upstream whenever --create's base is a remote-tracking ref (the is_remote_tracking_branch(base) arm, citing #713) — and I reproduced the push.autoSetupRemote = true path exactly as written. One inline suggestion on the rationale sentence, which doesn't hold under git's default config.
One thing the paragraph under-describes: resolve_base_ref promotes a bare base to origin/<base> when the name exists on exactly one remote and not locally (the remotes.len() == 1 arm in src/commands/worktree/switch.rs), so --base release against a remote-only release lands in the same no-upstream state as the explicit --base origin/release the paragraph shows. Worth a few words if it fits, though the explicit form is the one #3912 hit.
Repro for the inline suggestion (git 2.55.0, default config)
$ git config --get push.default # unset → "simple"
$ git worktree add -b feature ../ft origin/release
$ git branch -vv
* feature 48b8215 [origin/release] r1
$ git push
fatal: The upstream branch of your current branch does not match
the name of your current branch. To push to the upstream branch
on the remote, use
git push origin HEAD:releaseUnder push.default = upstream it does what the paragraph says:
$ git -c push.default=upstream push --dry-run
To ../origin.git
48b8215..5c1fec7 feature -> releaseSo the unset protects the upstream configuration specifically; under simple both states refuse the bare push, just with different messages.
Also covers the bare `--base release` that resolve_base_ref promotes to `origin/release`, and corrects the same overstatement in the code comment above unset_upstream().
Problem
wt switch --create <name> --base origin/<branch>leaves the new branch with no upstream — deliberately, since git would otherwise set it to track the base (#713). Nothing inwt switch's help or the site docs says this happens or what to do about it, so the user is left with a branch that a baregit pushrefuses and no stated way to publish it. #3912 is the third thread to arrive at the same manualgit push --set-upstream origin <branch>step.Solution
One paragraph in the
Creating a branchsection ofwt switch'safter_long_help: what the unset is for, and the two ways to publish — the explicitgit push --set-upstream, or git'spush.autoSetupRemote = true, after which a baregit pushfrom the new worktree publishes the branch and configures its tracking. The paragraph also names the bare--base releaseform, whichresolve_base_refpromotes toorigin/releasewhen the name exists on exactly one remote and not locally, landing in the same no-upstream state.The rationale is scoped to
push.default = upstream, which is the configuration the unset actually protects: under git's defaultsimple, afeaturebranch trackingorigin/releaserefuses the bare push rather than pushing torelease. The same overstatement was in the code comment aboveunset_upstream()insrc/commands/worktree/switch.rs, corrected here alongside it.No behavior change — help text, its three generated mirrors, and one code comment.
Testing
Claims verified against scratch repos with a local bare
origin, usingtarget/debug/wtand git 2.55.0:Verification
Explicit remote base, and the bare remote-only base that resolves to it:
push.defaultunder a branch that tracksorigin/release:With
push.autoSetupRemote = trueset, a baregit pushfrom the new worktree:cargo test --test integration test_docs_are_in_syncregenerated the three mirrors (site page, skill reference, plugin skills mirror) and passes on a second run;cargo insta test --accept --test integration -- test_helprefreshedhelp_switch_long.Refs #3912 — automated triage