Repository navigation
Conversation
…h the server rejects Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — The dialog now disables feature-branch checkout for Push and Create PR because those actions do not commit changes and the server already rejects them. Commit workflows and explicit continuation on the current branch are unchanged. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
|
Note Written by Verified in a real dev environmentVerified unchanged head
Short runtime transcript from the real repository and bare origin:
Before, main with the invalid feature-branch action enabled: After, the same data on the PR head: The 10-second recording shows the Push guard, Abort, the still-enabled commit feature-branch option, and a successful Push to main. Inspected the capture and verified uploaded playback. Not verifiedNative desktop shell, iOS/Android, macOS/Windows, remote/relay/tunnel connections, and providers other than Codex were not exercised on this Linux VM. Hosted PR creation and the |



Problem
On web, if you're on the default branch with unpushed commits and uncommitted changes, the Git menu's Push is enabled (since #15625, Push no longer needs a clean tree). Clicking it opens the "Push to default branch?" dialog, and Check out feature branch & continue is enabled there. Clicking that sends
pushwithfeatureBranch: true. The server rejects every non-commit action that asks for a feature branch (GitManager.runStackedAction: "Feature-branch checkout is only supported for commit actions."), so the user just gets an "Action failed" toast.#18716 fixed this for clean trees. The dirty-tree case for
push(andcreate_pr) was still open.Change
resolveFeatureBranchUnavailableReasonnow also takes the pending action. Forpushandcreate_prit returns a reason, so the button is disabled and the dialog explains why. This uses the same pattern #18716 added for clean trees. Commit actions on a dirty tree still offer the feature branch. Mobile already handles this case:GitConfirmSheetonly sendsfeatureBranch: truewhen the action includes a commit.Scope and approval
Very small, focused fix for an obvious bug, so no prior issue: the web client offers a button the server always rejects, and the fix lines the existing guard up with the server's precondition (1 line in
GitActionsControl.tsx, a few in the logic helper, plus one test). Overlap search: the local PR index and GitHub search turned up only #18716 (the merged clean-tree fix this extends) and its issue #18702. Open PRs #28652 and #29619 touch other git-action states, not this dialog.Verification
vp test run src/components/GitActionsControl.logic.test.tsfailed atassert.isNotNull(reason("push", true))withAssertionError: expected null to not equal null.vp run check:changed: format, lint, knip, typecheck (2 packages), test, and react compiler all pass.Reviewed with sol-loop: 1 round with GPT-6.1 Sol on high. Sol verdict: approved.
Created with Claude Opus 5.5 in Claude Code (T3 Code).
🤖 Generated with Claude Code