fix: reject an existing bare repository as an init destination

[ashproto]

Reported by Codex review on #26 as P2. The code is not part of that PR — crates/git-core/src/git_ops.rs is untouched by #26, and the guard came from 15e51c3 (2026-07-17) — so it is fixed here on its own branch, same as #27.

The gap

initialize_repository guards against an existing repository two ways, and a bare one slips between them:

guard	bare repo
destination.join(".git").exists()	false — a bare repo has no .git child
is_inside_worktree(destination)	false — rev-parse --is-inside-work-tree says false inside a bare repo

The destination is non-empty, so the user gets the "folder is not empty" prompt rather than "already a Git repository". On confirming, git init runs with the bare repository as its working directory.

What actually happens

Verified against real git rather than assumed — this is the exact command git_ops.rs issues, cwd set to a bare repo holding a real branch:

$ (cd bare.git && git init --initial-branch=newbranch)
Initialized empty Git repository in …/bare.git/.git/

nested .git created?  YES
bare HEAD after:      refs/heads/main     (unchanged)
refs still present:   refs/heads/trunk    (unchanged)
core.bare after:      true                (unchanged)

$ diff -rq bare-backup.git bare.git
Only in bare.git: .git

So it is a wrong state, not data loss — the bare repo survives intact and the only change is the nested .git. Worth stating plainly since "mutates a directory that should have been rejected" could read as destructive. It is still exactly what the sibling guard exists to prevent, and the app then reports success and opens the nested repo.

The fix

Probe the destination itself with rev-parse --resolve-git-dir:

if destination.join(".git").exists() || is_git_dir(&destination) {
    return Err("That folder is already a Git repository. Open it instead.".to_string());
}

I characterised the probe against every shape before picking it, because the risk is over-reach — refusing a legitimate destination:

path	--resolve-git-dir
bare repo dir	OK ← the case being fixed
normal repo .git	OK
normal repo root	fail
plain empty dir	fail
subdir inside a normal repo	fail ← does not walk up
nonexistent path	fail

That last row is the important one: --resolve-git-dir answers for the path given, so a plain folder that merely sits inside a repository is still a valid destination. Nesting remains is_inside_worktree's job, and a test now pins that boundary.

The .git check is kept alongside rather than replaced, so nothing refused before is accepted now.

The operand is always absolute (parent is fs::canonicalized before the join), so it cannot be read as a flag — noted in the doc comment since the project's shell-out rule would otherwise want a --, which --resolve-git-dir cannot take because it consumes the next argument.

Tests (TDD)

• initialize_repository_rejects_an_existing_bare_repository — watched fail first, returning Ok(initialized: true, existing_entries: 7). Asserts the error and that no nested .git was created.
• initialize_repository_still_accepts_a_plain_empty_folder — the over-reach guard. Passed before the change and after.

Both run with cwd inside a repository (cargo's working dir), so the "already inside a repo" case is exercised naturally.

Gates: cargo test full workspace green (git-core 185) · npm run check 524 files / 0 errors · npm test 330 passed.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

git-it/crates/git-core/src/git_ops.rs

Lines 118 to 120 in a6673e8

	&parent
	};
	if is_inside_worktree(nesting_probe) {

Reject Git directories used as repository parents

When the selected parent is itself a bare repository or a normal repository's .git directory and the requested child does not exist, nesting_probe becomes parent, but --is-inside-work-tree returns false in Git directories. The flow consequently creates the new repository inside the existing repository's metadata directory; check is_git_dir(&parent) as well so these parent selections are rejected before filesystem mutation.

---

git-it/package.json

Line 40 in a6673e8

"vite": "^8.1.4",

Declare the Node runtime required by Vite 8

The upgrade to Vite 8 raises the runtime requirement to Node ^20.19.0 || >=22.12.0 (recorded in package-lock.json), while package.json has no engines field and the build-from-source instructions specify no Node version. Contributors following those instructions with Node 18 or early Node 20 can install with only engine warnings and then fail when running the documented build commands; declare the requirement or retain a compatible toolchain.

ℹ️ 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]

Both addressed in 4ddc2af.

Git directory as parent — confirmed, and it is the same blind spot this PR fixes, one level up. I guarded the destination; the parent has the identical hole. Probed both candidates:

normal/.git    --is-inside-work-tree=false   is_git_dir=true
bare.git       --is-inside-work-tree=false   is_git_dir=true

With the destination not yet existing the nesting probe falls back to the parent, which answers false, so the flow proceeded. Reproduced end-to-end through initialize_repository: selecting host/.git as the parent produced

InitializeRepositoryResult { path: ".../host/.git/proj", initialized: true, existing_entries: 0 }

— a whole repository inside another repository's metadata. is_git_dir(&parent) now rejects it before any filesystem mutation, with a message naming the real problem rather than reusing the nesting one. initialize_repository_rejects_a_git_directory_as_parent covers both shapes and asserts nothing was created; it was watched failing first.

Node floor — confirmed. node_modules/vite 8.1.5 in the lockfile declares {"node": "^20.19.0 || >=22.12.0"}, package.json had no engines, and the build-from-source section named no version. Declared in engines and stated in the README beside the commands it governs. CI already runs Node 24, so this documents the existing requirement rather than changing it.

That second one is unrelated to bare-repo detection; fixed here anyway so the review converges on one branch rather than spawning another PR.

cargo test 186 + 7 passed · clippy clean · npm run check 524 files / 0 errors · npm test 330 passed.

[chatgpt-codex-connector]

💡 Codex Review

git-it/src/routes/+page.svelte

Line 298 in 4ddc2af

window.addEventListener("contextmenu", suppressNativeContextMenu);

Preserve native menus outside custom context-menu targets

Because this window-level listener unconditionally calls preventDefault(), right-clicking editable controls such as commit-message fields, repository descriptions, search boxes, and settings inputs no longer exposes the native Cut/Copy/Paste menu. Only suppress the event when a custom app context menu is actually being opened, or exempt input, textarea, and contenteditable targets.

ℹ️ 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]

Correct about the behaviour, but it is not this PR — and it is already fixed.

src/routes/+page.svelte is untouched by #29 (which changes git_ops.rs, package.json and README.md). The unconditional preventDefault() you flagged came from 15e51c3 (2026-07-17) and was the entire subject of #27, which took the same approach you suggest — exempting targets where text is selectable — and earned a 👍 before merging as 6856964.

You saw the old code because this branch was cut from next before #27 landed. I have merged next in (50d15f8), so the fix is now present here at +page.svelte:305:

const style = el && getComputedStyle(el);
if (style && (style.webkitUserSelect || style.userSelect) !== "none") return;
event.preventDefault();

It reads the computed user-select rather than listing element types, so it covers input/textarea/contenteditable and the app's wider allowlist (.diff-cell, .md, .body-msg, .sha, .selectable and their descendants), while the diff gutter keeps suppressing its own menu. Verified against the live stylesheet before merging.

Gate after the merge: cargo test 232 + 7 passed · clippy clean · npm run check 530 files / 0 errors · npm test 386 passed.

[chatgpt-codex-connector]

💡 Codex Review

git-it/src/lib/store.svelte.ts

Lines 1684 to 1688 in 50d15f8

	// Switching to ANOTHER repo: deliberately KEEP the previous repo's graph,
	// refs, status and working changes on screen until reloadGraph() swaps in
	// the new repo's data. Clearing them here flashed the header branch chip,
	// sidebar and status bar empty mid-switch (the reported flicker). A
	// stale-load guard in reloadGraph() prevents cross-repo contamination.

Block ref actions while the new repository loads

On an A → B switch, repo becomes B while this deliberately retains A's graph and refs. The main graph is replaced with a skeleton, but Sidebar continues rendering the retained refs and its checkout, delete, and fast-forward handlers execute against the current appState.repo. During a slow reload, clicking an old row can therefore operate on a same-named branch in B, including deleting it; clear the repo-affiliated state or disable all sidebar ref actions while repoLoading is true.

---

git-it/src/lib/updater.svelte.ts

Lines 131 to 133 in 50d15f8

	if (!available) return;
	if (manual) {
	if (pendingAutomaticUpdate?.version === available.version) pendingAutomaticUpdate = null;

Clear queued automatic updates before every manual check

If an automatic beta update is queued while Settings is open, the user can switch to stable and run a manual check. When that check returns no update—or a different version—the backend pending-update slot is cleared or replaced, but this UI queue is retained because it is only cleared for the same version. Closing Settings then presents the stale beta prompt, whose Download action either fails with no pending update or downloads a version different from the one displayed; invalidate the queued automatic update whenever a manual check starts or completes.

ℹ️ 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]

Both fixed in 87a0114. Neither is in this PR's diff (still git_ops.rs, package.json, README.md) — they are pre-existing on next — but fixing them here keeps the review on one branch.

P1 — sidebar acting on the wrong repository ✅

Confirmed structurally: set repo assigns the new path while deliberately retaining the previous repo's refsDetailed/worktrees, and Sidebar has no repoLoading gate, so its handlers run against appState.repo. With a name both repos have — main, develop — Delete Branch hits the wrong repo, and nothing prompts a second time for that.

Of your two suggestions I took the second. Clearing the repo-affiliated state would reintroduce the exact flicker the retention exists to prevent (documented at the retention site: clearing "flashed the header branch chip, sidebar and status bar empty mid-switch"). So the rows stay and the actions go inert while repoLoading — which reloadGraph clears in a finally, guarded so a superseding switch does not clear it early.

Covered: checkout, delete (including the Linked Worktrees panel, which routes through the same confirmDeleteBranch), and the ref context menu — which bails before the menu is built, so Checkout/Fast-forward/Delete are unreachable rather than merely guarded. Selection and scrolling stay live; they read nothing and write nothing.

One you did not mention, same root cause: the detached-HEAD menu. "Create branch here" would use the old repo's HEAD sha — and two clones of one project share commit ids, so that can quietly succeed in the wrong repository rather than erroring on an unknown sha. Gated too.

P2 — superseded automatic update ✅

Confirmed, and both holes reproduce. Regression tests written first and watched fail:

× drops a queued automatic update when a manual check finds nothing
    expected "confirm" not to be called, but was called 1 time
× drops a queued automatic update when a manual check finds a different version
    expected "confirm" to be called once, but got 2 times

The queue is now dropped when a manual check starts, which covers both the nothing-found and different-version cases the exact-version match missed. The retry timer needs no cancelling — it re-reads the variable and stops on its own. The old same-version clear is removed as dead.

npm run check 530 files / 0 errors · npm test 388 passed · cargo test 232 + 7 · clippy clean.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 87a0114bb2

ℹ️ 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".