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