fix(switch): track a remote base only when the names match

[worktrunk-bot]

Problem

wt switch --create <name> --base origin/<branch> ran git branch --unset-upstream afterwards, so the new branch could not push to the base (#713). Nothing said so, and #3912 was the third thread to arrive at the manual git push --set-upstream origin <branch> step. Reviewing the docs for it (@max-sixty, comment) surfaced the better question: should this just copy git?

Solution

Git already ships the rule the unset was approximating — branch.autoSetupMerge = simple sets tracking only when the start point is a remote-tracking branch and the new branch has the same name as the remote branch. wt now defaults to it on the --create paths instead of undoing git's true after the fact, and documents it in one paragraph of wt switch's after_long_help.

Three things follow:

• A same-named branch keeps its tracking. --create release --base origin/release was getting unset too, though the tracking it lost was correct.
• An explicit branch.autoSetupMerge is honoured. wt picks a different default; it no longer overrides the setting.
• --create off a remote base no longer fails outright for anyone whose config left git no upstream to unset. Under branch.autoSetupMerge = false the command exited 128 — fatal: branch 'feature' has no upstream information — after creating the branch and the worktree.

The DWIM paths (wt switch release when only origin/release exists) are unaffected: they create feature from origin/feature, where simple and true agree. simple needs git ≥ 2.37; MINIMUM_GIT_VERSION is 2.43.

Testing

test_switch_create_from_remote_base_no_upstream becomes test_switch_create_from_remote_base_upstream, covering the same #713 property plus the three cases above. Full suite via cargo run -- hook pre-merge --yes.

Verification (git 2.55.0, debug wt, bare origin with main and release)

Behavior, before and after, in a clone with no local release:

$ wt switch --create feature --base origin/release --no-cd   # default config
$ git branch -vv
+ feature 9e98944 (…/src.feature) r2                          # no upstream — unchanged

$ git config branch.autoSetupMerge false                      # before: exit 1
$ wt switch --create feature --base origin/release --no-cd
✓ Created branch feature from origin/release and worktree @ …/src.feature
+ feature 9e98944 (…/src.feature) r2

$ git config branch.autoSetupMerge always                     # before: unset anyway
$ wt switch --create feature --base origin/release --no-cd
+ feature 9e98944 (…/src.feature) [origin/release] r2

$ wt switch release --no-cd                                   # DWIM, unchanged
+ release 9e98944 (…/src.release) [origin/release] r2

The failure this removes, on the pre-change binary:

$ git config branch.autoSetupMerge false
$ wt switch --create feature --base origin/release --no-cd
✗ git branch --unset-upstream -- feature failed (exit 128)
  fatal: branch 'feature' has no upstream information
$ git worktree list
/tmp/asm2/src         257f014 [main]
/tmp/asm2/src.feature 653f0dd [feature]                       # created, then the command failed

branch.autoSetupMerge semantics, straight from git, no wt involved:

$ git switch -c t-true origin/release                              # default `true`
* t-true aeb85e2 [origin/release] r2
$ git -c branch.autoSetupMerge=simple switch -c t-simple origin/release
* t-simple aeb85e2 r2
$ git -c branch.autoSetupMerge=simple switch -c release origin/release
* release aeb85e2 [origin/release] r2

And that git worktree add -b — the invocation wt actually runs — honours it the same way:

$ git -c branch.autoSetupMerge=simple worktree add -b wt-diff /tmp/asm/wt-diff origin/release
+ wt-diff aeb85e2 (/tmp/asm/wt-diff) r2
$ git -c branch.autoSetupMerge=simple worktree add -b foo /tmp/asm/foo origin/foo
+ foo aeb85e2 (/tmp/asm/foo) [origin/foo] r2

---

Refs #3912, #713 — automated triage

[worktrunk-bot]

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:release

Under push.default = upstream it does what the paragraph says:

$ git -c push.default=upstream push --dry-run
To ../origin.git
   48b8215..5c1fec7  feature -> release

So the unset protects the upstream configuration specifically; under simple both states refuse the bare push, just with different messages.

[max-sixty]

I'm confused though: if we switch to an upstream branch, don't we make a local branch and then that local branch has an upstream? or I'm thinking about it wrongly?

[worktrunk-bot]

You're thinking about it right — that's a different case from the one the paragraph covers, and the paragraph didn't say so.

wt switch release when only origin/release exists does exactly what you describe: local branch, upstream intact. The unset is gated on *create_branch (switch.rs#L1037-L1043), so it never fires on that path.

The difference is what the inherited tracking would point at. Switching to release gives a branch named release tracking origin/release — the names line up, so tracking is correct. --create feature --base origin/release gives a branch named feature tracking origin/release, i.e. pointing at someone else's branch, which is what #713 unset.

Pushed c51e0bb rewording the paragraph to name --create as the exception and say what the tracking would point at, rather than leaving it adjacent to the tracking-branch sentence with nothing marking the contrast.

Verified against a scratch repo (debug wt, git 2.55.0)

origin has main and release; the clone has no local release.

$ wt switch release --no-cd
✓ Created branch release (tracking origin/release) and worktree @ /tmp/scratch/src.release
$ git branch -vv
* main    54a1160 [origin/main] r1
+ release f7679ef (/tmp/scratch/src.release) [origin/release] r2

$ wt switch --create feature --base origin/release --no-cd
✓ Created branch feature from origin/release and worktree @ /tmp/scratch/src.feature
$ git branch -vv
+ feature f7679ef (/tmp/scratch/src.feature) r2            # no upstream
* main    54a1160 [origin/main] r1
+ release f7679ef (/tmp/scratch/src.release) [origin/release] r2

One corner: --create release --base origin/release — same name, so tracking would have been fine — also gets unset, since the condition doesn't compare names. wt already routes that one out with a hint (switch.rs#L616):

$ wt switch --create release --base origin/release --no-cd
↳ To switch to the remote branch, delete this branch and run without --create: wt remove --foreground release && wt switch release
✓ Created branch release from origin/release and worktree @ /tmp/scratch/src2.release

[max-sixty]

ok, does this act differently to git? do we need to document it?!

[worktrunk-bot]

Yes — this is the one place wt switch deviates from git, and that's the argument for documenting it.

Git sets the upstream on every form that creates a branch from a remote-tracking ref — git worktree add -b, git switch -c, git checkout -b, git branch — because branch.autoSetupMerge defaults to true. wt switch --create --base origin/release unsets it afterwards (switch.rs#L1031-L1043, #713). The no---create path you asked about last time matches git exactly — wt switch release is git's DWIM, upstream intact. So the deviation is scoped to --create off a remote base, which is exactly the sentence the paragraph adds.

The caveat is that the deviation only buys something under push.default = upstream, which isn't git's default. Under simple, git already refuses the bare push from a feature branch tracking origin/release, so on a default config the unset trades one refusal (no upstream configured) for another (upstream branch does not match). If you'd rather drop the deviation than document it, that's #713 to reopen — and this paragraph goes away with it. Documenting is the smaller move given #3912 is the third thread to land here.

One thing docs can't do: the surprise arrives at git push, in a worktree, minutes after the wt switch that caused it. The creation line (✓ Created branch feature from origin/release and worktree @ …) is silent about tracking, while the auto-created-from-remote path does say (tracking origin/release). Saying it there too would reach people who never open --help — separate change, happy to leave it.

Repro (git 2.55.0, default config, no wt involved)

origin has main and release; the clone has no local release.

$ git config --get branch.autoSetupMerge      # unset → true
$ git worktree add -b wtb ../wtb origin/release
$ git switch -c swb origin/release
$ git checkout -b cob origin/release
$ git branch brb origin/release
branch 'brb' set up to track 'origin/release'.

$ git branch -vv
  brb    4bc6718 [origin/release] r2
  cob    4bc6718 [origin/release] r2
* main   478fe79 [origin/main] r1
  swb    4bc6718 [origin/release] r2
+ wtb    4bc6718 (/tmp/gitcheck/wtb) [origin/release] r2

All four track origin/release. wt switch --create feature --base origin/release leaves feature with no upstream (repro in the comment above).

[max-sixty]

so should we just copy git's behavior?

[worktrunk-bot]

Not git's default — that's the config #713 reported an accidental push to master under. But git ships a second mode that is exactly the rule the unset was approximating, so "copy git" is available without giving that up: branch.autoSetupMerge = simple sets tracking only when the start point is a remote-tracking branch and the new branch has the same name as the remote branch. Git's default true drops that second clause; simple has been available since 2.37 and MINIMUM_GIT_VERSION is 2.43.

Pushed 61c66de switching to it — git -c branch.autoSetupMerge=simple worktree add -b … on the --create paths, and the post-hoc git branch --unset-upstream deleted (switch.rs#L967-L981). Three things change, and the third is the one that decided it for me:

• --create release --base origin/release keeps its tracking. The old condition didn't compare names, so it unset the one case where inherited tracking was right — the corner I flagged two comments up.
• An explicit branch.autoSetupMerge now wins. wt picks a different default; it no longer overrides always or inherit.
• wt switch --create --base origin/X was failing outright for anyone whose config left git no upstream to unset. With branch.autoSetupMerge = false it exited 128 with fatal: branch 'feature' has no upstream information — after creating the branch and the worktree. So the status quo was wrong however this question goes; both candidate answers fix it.

The docs paragraph stays but shrinks to naming the config, since the behavior is now a git setting rather than a wt invention. If you'd rather have plain true after all, it's that one commit to revert and the paragraph goes with it.

Verified against scratch repos (git 2.55.0, debug wt)

origin has main and release; the clone has no local release.

The failure on the pre-change binary:

$ git config branch.autoSetupMerge false
$ wt switch --create feature --base origin/release --no-cd
✗ git branch --unset-upstream -- feature failed (exit 128)
  fatal: branch 'feature' has no upstream information
$ git worktree list
/tmp/asm2/src         257f014 [main]
/tmp/asm2/src.feature 653f0dd [feature]

After, across configs:

$ wt switch --create feature --base origin/release --no-cd    # default config
+ feature 9e98944 (…/src.feature) r2                           # no upstream, as before

$ git config branch.autoSetupMerge false
$ wt switch --create feature --base origin/release --no-cd
✓ Created branch feature from origin/release and worktree @ …/src.feature

$ git config branch.autoSetupMerge always
$ wt switch --create feature --base origin/release --no-cd
+ feature 9e98944 (…/src.feature) [origin/release] r2

$ wt switch release --no-cd                                    # DWIM path, unchanged
+ release 9e98944 (…/src.release) [origin/release] r2

simple vs true in git itself, and on the worktree add -b form wt actually runs:

$ git switch -c t-true origin/release                              # default `true`
* t-true aeb85e2 [origin/release] r2
$ git -c branch.autoSetupMerge=simple switch -c t-simple origin/release
* t-simple aeb85e2 r2
$ git -c branch.autoSetupMerge=simple switch -c release origin/release
* release aeb85e2 [origin/release] r2

$ git -c branch.autoSetupMerge=simple worktree add -b wt-diff /tmp/asm/wt-diff origin/release
+ wt-diff aeb85e2 (/tmp/asm/wt-diff) r2
$ git -c branch.autoSetupMerge=simple worktree add -b foo /tmp/asm/foo origin/foo
+ foo aeb85e2 (/tmp/asm/foo) [origin/foo] r2

test_switch_create_from_remote_base_no_upstream becomes test_switch_create_from_remote_base_upstream and covers all four rows. Full suite via cargo run -- hook pre-merge --yes: two failures, both sandbox-environmental and unrelated — test_copy_ignored_preserves_file_executable_permissions (runner umask is 0002, so 0664 not 0644) and test_powershell_skipped_when_installed_no_profile.

[mjakl]

Thanks—this also addresses #3937. I encountered the failure with branch.autoSetupMerge=simple: Git creates the differently named branch without an upstream, then wt switch --create fails while trying to unset an upstream that does not exist. I filed #3937 before finding this PR.

[worktrunk-bot]

Thanks for the repro in #3937 — it ran unmodified against builds of both main and this branch, and yes, this PR fixes it. Full before/after matrix is on the issue; two parts worth carrying over here.

On main the failure isn't specific to simple: false and inherit fail identically, because the unset_upstream() call this PR removes was unconditional. Under this branch all three exit 0 with no upstream.

The flip side is that an explicit branch.autoSetupMerge = true (or always) now leaves the new branch tracking origin/main, where main unset it. That's the "your config wins" half of the change rather than a gap — wt only supplies simple as a default when you haven't set the key — but it is a real behavior change for anyone who set true deliberately.