fix: resolve an untracked selection into Unstaged once the lists are merged

[ashproto]

Reported by Codex review on the v0.4.0 promotion (#30). next is protected by a ruleset requiring a PR, so the fix lands here and #30 picks it up.

The bug

SectionPresence already documents the rule — presence describes lists on screen, not file states, and explicitly says the untracked case must report "unstaged" while merging. The component derived the three fields inline, and they disagreed about what "rendered" meant:

unstaged:  unstagedDisplay.some(...)   // merged display list  ✅
untracked: untrackedFiles.some(...)    // raw file state       ❌

So: select an untracked file with the sections separate, then enable Merge Untracked into Unstaged. Presence reports the path in both, resolveSection keeps the recorded "untracked", and the pane resolves to a section that renders no rows in that mode — nothing highlights, and the Unstaged header offers "Stage all" instead of "Stage".

The fix

Two parts, and the second is the one that makes the first safe.

1. The rule moves out of the component into renderedPresence in workingSection.ts — beside the type it builds and the resolver that consumes it. This rule has now been violated once per field (the unstaged half was the same bug, caught in #26 review), which is the argument for it being one tested function rather than three inline expressions that can drift.

2. untracked stops answering two questions through one field. It now answers only "is the Untracked section showing this row", which is false while merging. Whether the file is untracked — which selects git diff --no-index and disables hunk staging — now reads from the file list directly and is unaffected by the mode, which is what that call always needed. Had I only changed presence, selectedIsUntracked would have flipped to false for merged untracked files and fetched the wrong diff.

The Untracked section header also consults it, but that section renders only when NOT merging, so the two readings coincide there.

Tests

Five new cases on renderedPresence, including the merged one and an end-to-end pairing with resolveSection:

renderedPresence("n.txt", files, false)  -> { untracked: true }
renderedPresence("n.txt", files, true)   -> { unstaged: true }
resolveSection("untracked", before)      -> "untracked"
resolveSection("untracked", after)       -> "unstaged"

Watched failing first — the type gate reported has no exported member 'renderedPresence' before the function existed.

npm run check 530 files / 0 errors · npm test 393 passed (up from 388) · cargo test 232 + 7.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

git-it/src/lib/components/Sidebar.svelte

Line 120 in 49cf239

await gitActions.deleteBranch(

Revalidate the repository after branch-delete confirmation

If the user leaves this confirmation open and switches repositories through the newly added native Open Repository… menu, refActionsBlocked() has already run and the dialog remains pending. Confirming afterward passes the old branch name and options to gitActions.deleteBranch, which operates on the now-current repository; when both repositories contain that branch name, this can delete the wrong branch (including force-deleting it). Capture the repository before opening the dialog and abort or retarget if it changes before this call.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ashproto]

Confirmed and fixed in 3d8f409. This is the same time-of-check/time-of-use shape as the stale-diff guard on discard, and I should have recognised it when I wrote refActionsBlocked() — that guard only covers the instant of the click, and every one of these then waits on a prompt with no timeout.

Extended past the reported site. Six other call sites in Sidebar.svelte have the identical gap, three of them destructive. Fixing only branch-delete would have left the same P1 in six places:

awaits	then calls
confirmBranchDelete	deleteBranch	reported
prompt	renameBranch
prompt	createTag
prompt	createBranch (from ref)
confirm	deleteRemoteBranch	destructive
confirm	deleteTag	destructive
prompt	createBranch (detached HEAD)

sameRepoAfterPrompt() captures appState.repo before the await and returns a predicate checked after it — a predicate rather than a callback wrapper so each call site keeps its own control flow readable. On mismatch it refuses and says so plainly ("Repository changed while that dialog was open — nothing was done") rather than failing silently or acting on a guess.

I audited every await dialogs. in the file afterwards to confirm none was missed — all 7 now capture before the await and check after it.

Your "capture the repository before opening the dialog" is what I implemented; I did not take the "or retarget" alternative. Retargeting would silently apply an action the user authorised against a different repository's state — the branch they confirmed deleting is not the branch they would be deleting.

npm run check 530 files / 0 errors · npm test 393 · cargo test 232 + 7.