fix(core): keep branch commits made by a failing post-checkout hook - #11300

Local verification — merge-ready, no blockers

I rebuilt the failure from #11253 in a real environment rather than reading the diff: real repositories, real post-checkout hooks, and a real qwen serve daemon. The PR's merge base ac01395 and its head c197a04 were run side by side, with plain git checkout -b as a third, oracle arm.

The fix is correct, effective and well covered. I found nothing blocking. The one thing I would follow up on is that a sibling copy of the same rollback lives in the CLI and is untouched (N1).

What I ran

• Module level. Each arm's own gitCreateBranch, compiled out of its worktree and driven over 21 throwaway repositories with real post-checkout hooks. The data-loss oracle is git fsck --unreachable --no-reflogs; the keep warning is read back out of the real debug log file (QWEN_HOME + QWEN_DEBUG_LOG_FILE=1), not a mock.
• Suite level. packages/core/src/utils/git-branches.test.ts on both arms, plus a negative control (the PR's tests against the base's production source) and three mutations of the fix.
• Product level. One CLI bundle built per arm, each run as a real qwen serve daemon and driven over HTTP on both branch-creation routes.

Scenario matrix

9 of 21 scenarios flip from silent data loss to preserved, 10 are identical on both arms, none regressed. Wherever the hook creates a commit, the head arm's outcome now matches what plain git does with the same hook.

Two notes that keep the severity honest:

• The orphaned commit is still named by the HEAD reflog, so before this fix it was recoverable with git reflog until the entry expires (git's 30-day gc.reflogExpireUnreachable default). The pre-fix behaviour is silent orphaning, not immediate destruction — still worth fixing, but a smaller claim than "the commit is gone".
• An unborn HEAD cannot reach this path at all: git does not run post-checkout when checkout -b creates a branch from an unborn HEAD (checked directly), so the command succeeds and no rollback happens. That is what makes the rev-parse fail-safe added in c197a04 cheap — I could only reach that branch of the code with a shimmed git.

Does the added test discriminate the fix?

Yes, in both directions. Three of the four added tests fail against the base's production source, and three targeted mutations of the fix are each killed by the suite. The single failure present in every run (gitPull … lock hint) also fails at the merge base — it is an artefact of running this suite as root here, untouched by the PR.

End to end on a real daemon

POST /workspace/git/branch — the daemon route behind DaemonClient.createBranch(), and the only production caller of gitCreateBranch — goes from "branch deleted, hook commit orphaned" to "branch and commit both survive". That is the fix doing real work on a real product surface, not just in unit tests.

Non-blocking observations

N1 — the same rollback shape survives in the CLI. rollbackBranchCreation (packages/cli/src/serve/routes/session.ts:948, reached from four call sites) restores the base ref and then calls deleteBranch unconditionally — exactly the pattern this PR replaces in core. It never goes through gitCreateBranch; it has its own createBranch in serve/server/git-branch-ops.ts. Driving POST /session {"branch":{"name":"topic"}} against the head bundle with the same hook still deletes the branch and orphans the commit (bottom half of the screenshot above). One nuance I measured: that delete is only reached when the restore checkout itself succeeds, i.e. when the hook fails only on the new branch — a hook that fails unconditionally makes rollbackBranchCreation bail out early and the branch survives by accident. I would leave this PR as it is and open a follow-up for session.ts rather than widen the diff, but it is worth saying on the issue, because Fixes #11253 will auto-close a report whose most user-visible path is still broken.

N2 — on the only production caller, the keep is completely silent. Round 1 already noted the debugLogger.warn "lands in the debug log only". Measured on the daemon it is stronger than that: createDebugLogger writes only while a DebugLogSession is active, and the daemon's HTTP route has none (setDebugLogSession is called from Config alone). With QWEN_DEBUG_LOG_FILE=1 the daemon log holds the route's [ERROR] route=POST /workspace/git/branch line and no GIT_BRANCHES line at all. The caller gets a 500 whose body is git's own Switched to a new branch 'topic' text, plus a branch it did not ask to keep. Not blocking — a surviving branch beats a dead commit — but if this is ever surfaced, the route's own daemonLog is the place.

N3 — the guard tests "the ref moved", not "the branch gained history". newHead !== startCommit also fires when a hook only rewinds the new branch (git reset --hard HEAD~1, a "reset to the release tag" hook), leaving a stray branch behind and logging "contains commits created after checkout" for a branch that contains strictly fewer. See the "hook only rewinds the branch" row: base deletes, head keeps. Harmless — a stray branch, not lost work — and arguably the safer default. A one-line ancestry test removes it; I ran it as a probe and the suite stays green (105 pass / 1 pre-existing fail, same as shipped) while the stray branch disappears:

const rewound = startCommit
  ? await runGit(cwd, ['merge-base', '--is-ancestor', newHead, startCommit], env)
      .then(() => true)
      .catch(() => false)
  : false;
if (newHead && newHead !== startCommit && !rewound) {

Your call whether that earns an extra subprocess on the failure path.

N4 — two shapes the new tests do not cover. The rewind shape from N3, and gitCreateBranch called inside a linked git worktree checkout. The worktree case behaves correctly on the head arm — the branch and the hook commit both survive — it is simply untested.

Not verified

• macOS and Windows. Everything above is Linux, git 2.47.3, Node 22.22.2.
• Concurrent branch creation against the same workspace.
• The branch-picker UI listing after a kept branch (already declared out of scope in the PR body).

Status at c197a04

Lint & Static is green; Test (ubuntu) was still running when I posted this. The only thing still holding the merge is the round-3 bot CHANGES_REQUESTED, which is stale — its findings were addressed and @yiliang114 approved at this same head afterwards.

const rewound = startCommit
  ? await runGit(cwd, ['merge-base', '--is-ancestor', newHead, startCommit], env)
      .then(() => true)
      .catch(() => false)
  : false;
if (newHead && newHead !== startCommit && !rewound) {

🤖 Generated with Claude Code — Claude Opus 5 (1M context)

@qwen-code /triage