wt switch --create exits 1 after creating the worktree with branch.autoSetupMerge=simple

[mjakl]

Summary

With branch.autoSetupMerge=simple, creating a branch whose name differs from its remote base leaves the new branch without an upstream, as documented by Git.

Worktrunk then unconditionally runs git branch --unset-upstream for a remote-tracking base. Git reports that there is no upstream to unset, and Worktrunk exits 1.

By that point, the branch and worktree have already been created successfully. With --format=json, stdout is empty, so automation receives a failure and no result even though the requested worktree exists.

Environment

$ uname -srmo
Linux 7.1.9-arch1-2 x86_64 GNU/Linux
# exit 0

$ wt --version
wt v0.75.0
# exit 0

$ git --version
git version 2.55.0
# exit 0

$ git config --show-origin --get branch.autoSetupMerge
file:.git/config	simple
# exit 0

The reproduction below isolates both Git and Worktrunk from user configuration. It uses only repository-local Git configuration and a local bare remote.

Minimal deterministic reproduction

#!/usr/bin/env bash
set -euo pipefail

tmp=$(mktemp -d /tmp/wt-v075-repro.XXXXXX)
trap 'rm -rf "$tmp"' EXIT

# Do not read the user's Git or Worktrunk configuration.
export HOME="$tmp/home"
export XDG_CONFIG_HOME="$tmp/xdg"
export GIT_CONFIG_GLOBAL=/dev/null
export GIT_CONFIG_SYSTEM=/dev/null
mkdir -p "$HOME" "$XDG_CONFIG_HOME"

# Create a local bare remote with one commit on main.
git init --bare --quiet --initial-branch=main "$tmp/origin.git"
git clone --quiet "$tmp/origin.git" "$tmp/seed"
printf 'initial\n' >"$tmp/seed/README.md"
git -C "$tmp/seed" add README.md
git -C "$tmp/seed" \
  -c user.name='Repro User' \
  -c user.email=repro@example.invalid \
  commit --quiet -m initial
git -C "$tmp/seed" push --quiet origin main

# Fresh clone containing only repository-local autoSetupMerge configuration.
git clone --quiet "$tmp/origin.git" "$tmp/repo"
git -C "$tmp/repo" config --local branch.autoSetupMerge simple
cd "$tmp/repo"

git config --show-origin --get branch.autoSetupMerge

set +e
wt switch --create oscar/recover-worktrunk \
  --base origin/main \
  --no-cd \
  --format=json \
  >"$tmp/stdout" 2>"$tmp/stderr"
status=$?
set -e

printf 'exit=%s\n' "$status"
printf 'stdout_bytes=%s\n' "$(wc -c <"$tmp/stdout")"
printf '%s\n' '--- stdout ---'
cat "$tmp/stdout"
printf '%s\n' '--- stderr ---'
cat "$tmp/stderr"

printf '%s\n' '--- resulting worktrees ---'
git worktree list --porcelain

printf '%s\n' '--- resulting upstream ---'
git for-each-ref \
  '--format=%(refname:short) upstream=%(upstream:short)' \
  refs/heads/oscar/recover-worktrunk

Actual result

Captured output from the failing command:

exit=1
stdout_bytes=0
--- stdout ---
--- stderr ---
✗ git branch --unset-upstream -- oscar/recover-worktrunk failed (exit 128)
  fatal: branch 'oscar/recover-worktrunk' has no upstream information

Despite that failure, the same run showed that the branch and linked worktree exist:

--- resulting worktrees ---
worktree /tmp/wt-v075-capture.agRkJW/repo
HEAD d8338b7e8fdefe481a2f871e3c7327ed215ba0aa
branch refs/heads/main

worktree /tmp/wt-v075-capture.agRkJW/repo.oscar-recover-worktrunk
HEAD d8338b7e8fdefe481a2f871e3c7327ed215ba0aa
branch refs/heads/oscar/recover-worktrunk

--- resulting upstream ---
oscar/recover-worktrunk upstream=

Running the failing Git operation directly confirms its exit status:

$ git branch --unset-upstream oscar/recover-worktrunk
fatal: branch 'oscar/recover-worktrunk' has no upstream information
# exit 128

The temporary repository shown above was removed after verification.

Expected result

The command should:

1. create the branch and worktree;
2. leave the new branch without an upstream, preserving the safety behavior from wt switch --create --base=origin/master sets upstream to master (dangerous) #713;
3. emit the normal {"action":"created", ...} JSON result; and
4. exit 0.

An absent upstream already satisfies the safety requirement. It should therefore be treated as success rather than as an error from the overall operation.

Cause and effect

Git documents branch.autoSetupMerge=simple as setting up tracking only when:

• the start point is a remote-tracking branch; and
• the new branch has the same name as the remote branch.

See git-branch documentation.

Here the names differ:

new branch:  oscar/recover-worktrunk
remote base: origin/main

The resulting sequence is:

1. Worktrunk creates oscar/recover-worktrunk from origin/main.
2. Because branch.autoSetupMerge=simple applies, Git does not configure an upstream.
3. The branch and worktree now exist and are in the desired safe state.
4. Worktrunk recognizes origin/main as a remote-tracking base and calls unset_upstream() unconditionally.
5. git branch --unset-upstream exits 128 because there is nothing to unset.
6. Worktrunk propagates that as exit 1 before emitting the JSON result.

The relevant v0.75.0 code is:

• the unconditional safety call in switch.rs
• unset_upstream() propagating the Git command failure

This safety path originated in #713 and PR #717.

At the time of this report, source inspection of main at e5f9589c showed the same unconditional call.

Control

A fresh clone with branch.autoSetupMerge=true does not fail:

$ git config --local branch.autoSetupMerge true
# exit 0

$ wt switch --create oscar/recover-worktrunk --base origin/main --no-cd --format=json
{"action":"created","branch":"oscar/recover-worktrunk","path":"/tmp/worktrunk-v075-repro.mD6nA3/control-true.oscar-recover-worktrunk","created_branch":true,"base_branch":"origin/main"}
✓ Created branch oscar/recover-worktrunk from origin/main and worktree @ /tmp/worktrunk-v075-repro.mD6nA3/control-true.oscar-recover-worktrunk
↳ To customize worktree locations, run wt config create
# exit 0

$ git for-each-ref \
    '--format=%(refname:short) upstream=%(upstream:short)' \
    refs/heads/oscar/recover-worktrunk
oscar/recover-worktrunk upstream=
# exit 0

With true, Git creates the tracking relationship for a remote-tracking start point, so Worktrunk has an upstream to remove. The final safe state is otherwise the same.

Verified workarounds

Recover after the failure

The failed invocation has already created the worktree. Switch to the existing branch without --create:

$ wt switch oscar/recover-worktrunk --no-cd --format=json
{"action":"existing","branch":"oscar/recover-worktrunk","path":"/tmp/worktrunk-v075-repro.mD6nA3/failure.oscar-recover-worktrunk"}
○ Switched to worktree for oscar/recover-worktrunk @ /tmp/worktrunk-v075-repro.mD6nA3/failure.oscar-recover-worktrunk
# exit 0

Resolve the remote-tracking base to its commit first

This preserves the current origin/main commit while avoiding the remote-base cleanup path:

$ base=$(git rev-parse origin/main)

$ wt switch --create oscar/recover-sha \
    --base "$base" \
    --no-cd \
    --format=json
{"action":"created","branch":"oscar/recover-sha","path":"/tmp/worktrunk-v075-repro.mD6nA3/workaround-sha.oscar-recover-sha","created_branch":true,"base_branch":"1e80abd0b884ad69ed02fea298772235669be5bb"}
✓ Created branch oscar/recover-sha from 1e80abd0b884ad69ed02fea298772235669be5bb and worktree @ /tmp/worktrunk-v075-repro.mD6nA3/workaround-sha.oscar-recover-sha
↳ To customize worktree locations, run wt config create
# exit 0

$ git for-each-ref \
    '--format=%(refname:short) upstream=%(upstream:short)' \
    refs/heads/oscar/recover-sha
oscar/recover-sha upstream=
# exit 0

The created branch SHA was also verified to equal the resolved origin/main SHA.

Not verified

• I did not run the reproduction on operating systems or Git versions other than Linux x86_64 with Git 2.55.0.
• I did not build and run the current main branch; the statement about main above is source inspection only.
• I did not bisect Worktrunk releases to identify the first released version containing this failure.
• Other branch.autoSetupMerge values that can omit tracking, such as false, were not tested.

This report was generated by an AI coding agent. The reproduction and outputs were verified locally before posting.

[mjakl]

PR #3913 addresses the underlying failure reported here. Its change covers the branch.autoSetupMerge=simple case where Git creates the new branch without an upstream and Worktrunk then tries to unset an upstream that does not exist. This issue can be closed when #3913 lands.

[worktrunk-bot]

Reproduced, and confirmed #3913 fixes it. I built main (1c5c63ba9) and #3913's head (61c66de11) and ran your script against each — it ran unmodified, on Linux x86_64 with git 2.55.0, the same version you reported.

On main the failure isn't specific to simple. The unset_upstream() call is unconditional, so every branch.autoSetupMerge value that declines to set tracking for a differently-named branch hits it:

branch.autoSetupMerge	main (1c5c63ba9)	#3913 (61c66de11)
unset (git's default)	exit 0, no upstream	exit 0, no upstream
simple	exit 1, empty stdout	exit 0, no upstream
false	exit 1, empty stdout	exit 0, no upstream
inherit	exit 1, empty stdout	exit 0, no upstream
true	exit 0, no upstream	exit 0, upstream origin/main
always	exit 0, no upstream	exit 0, upstream origin/main

That settles the false line in your "Not verified" section, and adds inherit next to it. In every failing case the worktree and branch existed afterwards, exactly as you described.

The two bold cells in the last column are deliberate, not a leftover. #3913 drops the unconditional unset and instead defaults branch.autoSetupMerge to simple for --create — but only when the key isn't already set. An explicit true or always is your configuration and now wins, so a branch created from origin/main keeps that upstream; the #713 hazard stops being reachable by default and remains reachable for anyone who opts into true on purpose.

Leaving this open to close when #3913 lands, as you suggested.

Verification detail

Both binaries were debug builds from a clean checkout, invoked through your script with only the wt path and the branch.autoSetupMerge value parameterized. The environment isolation was yours unchanged: HOME/XDG_CONFIG_HOME in the temp dir, GIT_CONFIG_GLOBAL=/dev/null, GIT_CONFIG_SYSTEM=/dev/null, local bare remote.

Representative main failure (inherit), matching your capture verbatim:

exit=1
stdout:
stderr: ✗ git branch --unset-upstream -- oscar/recover-worktrunk failed (exit 128)
  fatal: branch 'oscar/recover-worktrunk' has no upstream information
upstream=[]
worktrees=2

Same case on #3913:

exit=0
stdout: {"action":"created","branch":"oscar/recover-worktrunk","path":"…/repo.oscar-recover-worktrunk","created_branch":true,"base_branch":"origin/main"}
upstream=[]
worktrees=2

Not checked: Windows and macOS (#3913's own CI covers those for the test suite, but not this repro), and git versions other than 2.55.0.

[worktrunk-bot]

Fixed on main. #3913 merged as 4e9f706e9, and #3950 followed it as 1b4c492ee. I re-ran your reproduction unmodified against a build of main at 6a96ddfd7 (wt v0.75.0-24-g6a96ddfd7), on Linux x86_64 with git 2.55.0 — the same version you reported. Every branch.autoSetupMerge value now exits 0, emits the JSON result, and leaves oscar/recover-worktrunk with no upstream, which is the four-point expected result from your report.

One correction to my earlier table, since #3950 landed after it: I said an explicit true or always would keep upstream = origin/main. That is no longer the behavior. #3950 passes -c branch.autoSetupMerge=simple to git worktree add, and -c outranks every config file, so wt now decides tracking for a branch it creates on every machine regardless of what branch.autoSetupMerge is set to. The #713 hazard is unreachable rather than opt-in-able.

branch.autoSetupMerge	v0.75.0	main (6a96ddfd7)
unset (git's default)	exit 0, no upstream	exit 0, no upstream
simple	exit 1, empty stdout	exit 0, no upstream
false	exit 1, empty stdout	exit 0, no upstream
inherit	exit 1, empty stdout	exit 0, no upstream
true	exit 0, no upstream	exit 0, no upstream
always	exit 0, no upstream	exit 0, no upstream

The rule that replaced the unconditional unset is name-matching, and it holds in the other direction too: --create release --base origin/release does get origin/release as its upstream, under all four values I checked. That is the tracking the wt switch docs promise, so the fix removes the crash without removing the useful case.

Closing per your note that this could close once #3913 landed — thanks for the unusually complete report; the isolated repro is what made this verifiable end to end. If you hit anything else here, say so and we'll reopen.

Verification detail

Debug build from a clean checkout of main at 6a96ddfd7. Your script ran with only the wt path and the branch.autoSetupMerge value parameterized; environment isolation unchanged from yours (HOME/XDG_CONFIG_HOME in a tempdir, GIT_CONFIG_GLOBAL=/dev/null, GIT_CONFIG_SYSTEM=/dev/null, local bare remote). In all six runs git worktree list --porcelain reported 2 worktrees and stdout carried {"action":"created","branch":"oscar/recover-worktrunk",...}.

Same-name control, wt switch --create release --base origin/release:

same-name  autoSetupMerge=unset    upstream=origin/release
same-name  autoSetupMerge=simple   upstream=origin/release
same-name  autoSetupMerge=true     upstream=origin/release
same-name  autoSetupMerge=false    upstream=origin/release

Not checked: Windows and macOS (#3913's and #3950's own CI cover those for the test suite, but not this repro), and git versions other than 2.55.0.