Misc. bug: build-info.cmake reports an unrelated repository's commit when a release tarball is built inside a git tree

[mattafaak]

Name and Version

$ llama-server --version
version: 0.3.0-dev (build 10797, commit 235f4e8)

That commit string is the bug: 235f4e8 is not a llama.cpp commit. It belongs to an unrelated repository.

Operating systems

Linux

Which llama.cpp modules do you know to be affected?

Build system (cmake/build-info.cmake) — affects every binary's --version output.

Problem description & steps to reproduce

cmake/build-info.cmake runs git rev-parse --short HEAD with WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} and accepts the result whenever RES EQUAL 0. It never checks that the repository git found is llama.cpp. Since git searches parent directories, unpacking a release tarball anywhere inside an unrelated git working tree makes BUILD_COMMIT that foreign repo's HEAD.

The failure is silent and confident: you get a plausible 7-hex string, so nothing looks wrong until someone tries to resolve it and gets a 404/422 — which reads like a broken API token rather than a wrong hash.

Minimal reproduction (no distro packaging involved, pristine release tarball):

$ mkdir outer && cd outer && git init -q . && git commit -q --allow-empty -m "unrelated repo"
$ git rev-parse --short HEAD
48530d7

$ curl -sSL https://github.com/ggml-org/llama.cpp/archive/refs/tags/b10797.tar.gz | tar xz
$ ls -d llama.cpp-b10797/.git
ls: cannot access 'llama.cpp-b10797/.git': No such file or directory   # tarball has no git metadata

$ cmake -S llama.cpp-b10797 -B build -DGGML_CUDA=OFF -DLLAMA_CURL=OFF >/dev/null
$ cat build/src/llama-version.h
#define LLAMA_VERSION "0.3.0-dev"
#define LLAMA_COMMIT  "48530d7"      # <-- the OUTER repo's HEAD

b10797 is actually 832fd6f. The build confidently reports a commit from a repository that has never contained llama.cpp.

This is not hypothetical. The Arch AUR package llama.cpp-cuda hits it on every build: makepkg extracts the release tarball into $srcdir inside the cloned package repo, and git is in makedepends, so the lookup succeeds and returns the packaging repo's HEAD. The two most recent versions report 235f4e8 and f268830, which are the AUR commits "ci(llama.cpp-cuda): update package to b10797-1" and "…b10783-1". Neither exists here. I've reported it downstream as well, but the same trap is open to any packager building a tarball inside a git checkout.

Why it's worth fixing rather than leaving to distros: this repo's own issue templates ask for the --version string, so the field is load-bearing for triage — and right now it can hand maintainers a commit from someone else's repository, pointing debugging at the wrong source.

Suggested fix. Verify the repository git found is the source tree before trusting it, e.g. compare

git -C ${CMAKE_CURRENT_SOURCE_DIR} rev-parse --show-toplevel

against ${CMAKE_CURRENT_SOURCE_DIR} and fall back to "unknown" on mismatch. "unknown" is honest; a foreign commit is not.

Packagers can already override explicitly — CMakeLists.txt:156 guards with if (NOT DEFINED LLAMA_BUILD_COMMIT) — and I confirmed that path works:

$ cmake -S llama.cpp-b10797 -B build2 -DLLAMA_BUILD_COMMIT=832fd6f ... && tail -1 build2/src/llama-version.h
#define LLAMA_COMMIT  "832fd6f"

so the fix here is only about the default not being confidently wrong.

First Bad Commit

Not a regression — the RES EQUAL 0 logic is long-standing. Verified on b10797 (832fd6f).

Relevant log output

$ llama-server --version
version: 0.3.0-dev (build 10797, commit 235f4e8)

# 235f4e8 in this repo:
$ gh api repos/ggml-org/llama.cpp/commits/235f4e8
gh: No commit found for SHA: 235f4e8 (HTTP 422)