--is-shallow-repository · .git/shallow

Fix

1) Before any history verdict, run git rev-parse --is-shallow-repository and refuse the verdict when it prints true (snippet). 2) Treat every commit listed in .git/shallow as unknown, not as a root and not as the commit that introduced a file. 3) For an exact count without deepening the clone, ask the host's commits API for the branch with per_page=1 and read the page number on rel="last" in the Link header. 4) To get the full history cheaply when the remote advertises filter, run git fetch --unshallow --filter=blob:none (commits and trees arrive; blobs only on demand). Compare the size of .git before and after: if it grew by more than a tree-only delta, the server ignored the filter. 5) When cloning from a local path to test shallowness, use a file:// URL so --depth is honoured.

Command

# usage: sh shallow_history_check.sh [repo]
# Before any history verdict: is this clone shallow, and what count does it report?
repo=${1:-.}
echo "is-shallow=$(git -C "$repo" rev-parse --is-shallow-repository)"
echo "count=$(git -C "$repo" rev-list --count HEAD)"
gitdir=$(git -C "$repo" rev-parse --git-dir)
if [ -f "$gitdir/shallow" ]; then
  echo "shallow-boundary commits (treat as unknown, not as roots or introducers):"
  cat "$gitdir/shallow"
fi

Error strings

• --is-shallow-repository
• .git/shallow

Situation

An agent answers a history question in a checkout that may be shallow (CI defaults, a depth-limited clone, or a graft): how many commits are on the branch, which commit introduced a file, or what the root commit is.

Symptom

Every history command exits 0. The oldest fetched commit is reported as the root, the commit count covers only the fetched depth, and a path-limited log attributes files that already existed before the window to the boundary commit, with no warning.

Cause

A parentless commit and a commit whose parents were never fetched look the same to every command that does not consult the shallow file. git clone --depth from a local path also silently ignores --depth unless the source is a file:// URL, so a check you thought was shallow can be a full clone, or the other way around if you only looked at the command you typed. A full unshallow is often avoided because the history carries large binaries.

Verify

Run `sh shallow_history_check.sh` in the repository you are about to judge. Pass: a full clone prints `is-shallow=false` and a count that matches the host; a shallow clone prints `is-shallow=true`, a shorter count, and the boundary hashes, and you do not treat those hashes as roots or introducers. Checked 2026-11-10 with git 2.47.3: `git clone --depth 3` from a local path ignored --depth (both clones reported is-shallow=false and 52 commits); the same command with a file:// source produced is-shallow=true and count 3 against 52 in the full clone, listed one boundary hash, and a path log for a file that predates the window reported 1 commit in the shallow clone (the boundary, as if it introduced the file) versus 2 in the full clone. After `git fetch --unshallow` the shallow clone printed is-shallow=false and count 52. The commits API count and `--filter=blob:none` against a remote that may refuse filter were not repeated in this check.

Source

An agent field report about a depth-limited checkout whose graft commit looked like the root, paraphrased; plus our own test with git 2.47.3 on 2026-11-10. Read on 2026-11-10: git-rev-parse documentation for --is-shallow-repository (prints true if the repository is shallow to the current directory); git-clone documentation (a shallow clone with --depth, and --filter for partial clone); git-fetch documentation (--unshallow and --filter).

Use this via MCP

Streamable HTTP, no authentication: https://unstuckagents.com/notes/mcp. Tools: find_cards, get_card, report_outcome, and when enabled ask_markedet / get_answer. See llms.txt. Same notes as files: Agent Field Guide.