prepare-llama.sh: prevent git -C from escaping into an enclosing repo - #780

Problem

scripts/prepare-llama.sh runs all of its git operations as git -C "$LLAMA_WORKDIR". git -C <dir> only changes directory — it does not pin git to that directory. If $LLAMA_WORKDIR (default .deps/llama.cpp) has no valid .git at the moment those commands run (an interrupted or partial clone, or a wiped .git), git's normal upward repository discovery walks past it to the nearest enclosing .git.

When mesh-llm is consumed as a git/cargo dependency, it gets vendored inside the consuming repo's working tree — cargo's git checkout dir and hermit's .hermit/rust/git/checkouts/... both do this. In that layout, the "nearest enclosing .git" that discovery finds is the consuming repo, so the script mutates it instead of the llama checkout.

Observed impact (real, in a consuming repo)

Triggered during a routine cargo clippy --workspace --all-targets that built mesh-llm:

1. Origin rewritten — git -C "$LLAMA_WORKDIR" remote set-url origin "$LLAMA_UPSTREAM_URL" resolved against the consuming repo and rewrote its remote.origin.url to https://github.com/ggml-org/llama.cpp.git. A later git push then attempted to push the consuming repo's commits to ggml-org/llama.cpp (it 403'd for us — no write access — so nothing leaked, but it was a wrong-destination push attempt).
2. HEAD clobbered — the git am --3way "${PATCHES[@]}" series applied onto the consuming repo's worktree HEAD: HEAD detached, several Mesh-LLM CI <[email protected]> commits stacked on top, working tree showing thousands of phantom deletions.

Both required manual repair. The danger is that it's silent (happens during a normal build, not an explicit git op) and, with write access to the rewritten upstream, the origin rewrite could exfiltrate the consuming repo's code.

Root cause

The clone guard [[ ! -d "$LLAMA_WORKDIR/.git" ]] only re-clones when .git is entirely absent. A partial/corrupt checkout (dir present, .git missing or incomplete) passes straight through to the git -C operations, and discovery then escapes upward.

Fix

Two minimal, behavior-preserving guards in scripts/prepare-llama.sh:

1. Pin discovery so it can't escape — export GIT_CEILING_DIRECTORIES to the absolute parent of $LLAMA_WORKDIR. Git discovery can no longer walk above that ceiling, so a missing/partial .git now errors loudly here instead of corrupting the parent repo. This closes every git -C call site at once (including the rev-parse HEAD in the "already prepared" fast-path).
2. Harden the clone guard — replace the bare [[ ! -d .../.git ]] with git rev-parse --git-dir, so a partial/corrupt checkout is re-cloned rather than passed through. clone_llama_workdir already rm -rfs before cloning, so re-cloning a partial dir is safe.

Why this is safe for mesh-llm's own build

In a normal mesh-llm build, $LLAMA_WORKDIR is a real clone with its own .git at the workdir — i.e. at/below the ceiling — so discovery still finds it and every operation behaves exactly as before. The ceiling only blocks discovery above the workdir's parent, which never happens on the happy path. The happy path is byte-for-byte unchanged; the only new behavior is that a missing/partial .git fails fast instead of escaping.

Verification

Local functional tests (not just review):

• Bug path — workdir with no valid .git inside an enclosing repo: without the ceiling, git -C resolves to the enclosing .git; with the ceiling, rev-parse --git-dir fails as intended (guard re-clones), and a remote set-url errors fatal: not a git repository instead of touching the parent. Enclosing origin unchanged before/after.
• Happy path — workdir with its own .git at/below the ceiling: rev-parse --git-dir succeeds, rev-parse --show-toplevel correctly resolves to the child workdir, and remote set-url affects only the child. Parent untouched.
• bash -n scripts/prepare-llama.sh clean.

Scope is limited to scripts/prepare-llama.sh — no refactor, no reformat, no changes to the patch flow or CI.