fix(git): reflect in-place branch checkout

[MattPua]

Problem

Switching branches from the task header succeeded, but the selector continued showing stale workspace metadata.

Changes

• Show the branch confirmed by the checkout mutation
• Keep syncing later branch changes from props
• Add regression coverage

How did you test this?

• pnpm --filter @posthog/ui test -- packages/ui/src/features/git-interaction/components/BranchSelector.test.tsx (1,998 tests passed)
• pnpm --filter @posthog/ui typecheck
• pnpm biome check packages/ui/src/features/git-interaction/components/BranchSelector.tsx packages/ui/src/features/git-interaction/components/BranchSelector.test.tsx
• Commit hook: pnpm typecheck

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

---

Created with PostHog Code

[trunk-io]

😎 Merged directly without going through the merge queue, as the queue was empty and the PR was up to date with the target branch - details.

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 1f5dab3.}

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/ui/src/features/git-interaction/components/BranchSelector.tsx:233-237
**Retained checkout masks prop updates**

When the current branch changes again for the same repository after a successful in-place checkout, the retained mutation result continues taking precedence over `currentBranch`, causing the selector to remain stuck on the earlier branch.

_{Reviews (1): Last reviewed commit: "fix(git): reflect in-place branch checko..." | Re-trigger Greptile}

[stamphog]

Note

🤖 stamphog reviewed b1326e505aa45c3d2afa27c24815765c1a3e3b53 — verdict: REFUSED

Greptile's unresolved review comment identifies a real, unaddressed bug: the new checkedOutBranch logic keeps showing the stale mutation result whenever repoPath matches, so a later currentBranch prop change is masked — reintroducing the same stale-display bug class this PR claims to fix.

• greptile-apps[bot] reviewed the current head.
• Unresolved inline comment from @greptile-apps on BranchSelector.tsx:233-237 — checkoutMutation.data takes precedence over currentBranch indefinitely (gated only on repoPath match), so a subsequent branch change for the same repo won't be reflected until another checkout mutation runs.
• No test covers this follow-up scenario (only the initial checkout-success case is added).

Gate mechanics and policy version

Gate		Result
prerequisites	✓	all clear
deny-list	✓	no deny categories matched
size	✓	8L, 1F substantive, 65L/2F incl. docs/generated/snapshots — within ceiling
tier	✓	T1-agent / T1b-small (65L, 2F, single-area, fix)
stamphog 2.0.0b3		.stamphog/policy.yml @ 0d728bc · reviewed head b1326e5

[greptile-apps]

The bug is real. Looking at lines 233-237:

const checkedOutBranch =
  checkoutMutation.data &&
  checkoutMutation.variables.directoryPath === repoPath
    ? checkoutMutation.data.currentBranch
    : currentBranch;

Once checkoutMutation.data is set, it wins over currentBranch for the entire lifetime of that mutation state (gated only on repoPath match). If a subsequent external branch change comes in via props — e.g. the task is switched, or the user checks out a branch from a terminal — the mutation data masks it.

The fix is to stop preferring mutation data once currentBranch has diverged from the pre-checkout value. The cleanest approach: capture the branch that was active before the checkout fires, and only show the mutation result while currentBranch is still that stale value.

Add a ref:

const preCheckoutBranchRef = useRef<string | null>(null);

Capture it before mutating (in handleBranchChange):

preCheckoutBranchRef.current = currentBranch;
checkoutMutation.mutate({
  directoryPath: repoPath as string,
  branchName,
});

Then update the derived value:

  const checkedOutBranch =
    checkoutMutation.data &&
    checkoutMutation.variables.directoryPath === repoPath &&
    currentBranch === preCheckoutBranchRef.current
      ? checkoutMutation.data.currentBranch
      : currentBranch;

This way:

• Immediately after checkout: currentBranch is still the old value (=== preCheckoutBranchRef.current), so mutation data is shown — fixes the original stale-display bug.
• After props catch up: currentBranch changes (either matching the checkout or an external change), the condition fails, and we fall back to currentBranch — no more masking.
• External branch switch: same as above; the ref never gets updated so currentBranch !== preCheckoutBranchRef.current immediately, restoring correct display.

A test covering the "subsequent prop change after checkout" case (checking out branch A, then receiving currentBranch=B from props) would close the coverage gap the reviewer flagged.

[github-actions]

Contained UI bug fix to branch-selector display logic with an added regression test; the diff's new previousBranch-comparison guard directly resolves the reviewer's "retained checkout masks prop updates" concern, and the change sits outside risky territory.

• 👍 on the PR from greptile-apps[bot].

Gate mechanics and policy version

Gate		Result
prerequisites	✓	all clear
deny-list	✓	no deny categories matched
size	✓	9L, 1F substantive, 80L/2F incl. docs/generated/snapshots — within ceiling
tier	✓	T1-agent / T1b-small (80L, 2F, single-area, fix)
stamphog 2.0.0b3		.stamphog/policy.yml @ 0d728bc · reviewed head 1f5dab3